14:02:41 #startmeeting Glance 14:02:42 Meeting started Thu Jun 25 14:02:41 2015 UTC and is due to finish in 60 minutes. The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:42 o/ 14:02:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:45 o/ 14:02:45 The meeting name has been set to 'glance' 14:02:46 o/ 14:02:48 o/ 14:02:48 #topic agenda 14:02:50 o/ 14:02:50 o/ 14:02:51 o/ 14:02:54 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:03:06 o/ 14:03:16 o/ 14:03:35 Welcome all 14:03:50 #topic Updates 14:03:53 o/ 14:04:01 o/ 14:04:28 #info Liberty-1 released on Tuesday. We had decent number of bug fixes done. 14:04:34 #link https://launchpad.net/glance/+milestone/liberty-1 14:06:06 There isn't much listed on Liberty-2 atm, #link http://status.openstack.org/release/ 14:06:31 Guess, first thing we need to do is plan features that need to merge by then 14:06:55 Please bring those up in the drivers meeting, so that people can prioritize and review them accordingly 14:07:15 rather what we can merge by then 14:07:25 yes 14:07:34 #topic Other Glance related meetings 14:07:59 To bring those up 14:08:06 see, #link http://eavesdrop.openstack.org/#Glance_Drivers_Meeting 14:08:13 and #link http://eavesdrop.openstack.org/#Glance_Artifacts_Sub-Team_Meeting 14:08:30 Will move on if nothing else 14:08:50 just ref those two 14:09:33 can we dedicate 2x 5min timeslots of the start of this meeting from now on to sunc updates from the previous Driver and Artifact meetings? 14:10:25 #startvote should we have? -- 2x 5min timeslots of the start of this meeting from now on to sunc updates from the previous Driver and Artifact meetings 14:10:25 Begin voting on: should we have? Valid vote options are --, 2x, 5min, timeslots, of, the, start, of, this, meeting, from, now, on, to, sunc, updates, from, the, previous, Driver, and, Artifact, meetings. 14:10:26 Vote using '#vote OPTION'. Only your last vote counts. 14:10:42 #vote yes 14:10:43 nikhil_k: yes is not a valid option. Valid options are --, 2x, 5min, timeslots, of, the, start, of, this, meeting, from, now, on, to, sunc, updates, from, the, previous, Driver, and, Artifact, meetings. 14:10:47 #vote yes 14:10:48 jokke_: yes is not a valid option. Valid options are --, 2x, 5min, timeslots, of, the, start, of, this, meeting, from, now, on, to, sunc, updates, from, the, previous, Driver, and, Artifact, meetings. 14:10:51 lol 14:10:56 that's a lot of options you've got there 14:10:57 #endvote 14:10:58 Voted on "should we have?" Results are 14:11:16 #startvote should we have, 2x 5min timeslots of the start of this meeting from now on to sunc updates from the previous Driver and Artifact meetings ? 14:11:17 Begin voting on: should we have, 2x 5min timeslots of the start of this meeting from now on to sunc updates from the previous Driver and Artifact meetings ? Valid vote options are Yes, No. 14:11:18 Vote using '#vote OPTION'. Only your last vote counts. 14:11:21 #vote yes 14:11:22 #vote yes 14:11:25 #vote yes 14:11:26 #vote yes 14:11:26 #vote yes 14:11:28 #vote yes 14:11:28 #vote yes 14:11:42 #vote yes 14:11:48 #vote yes 14:12:10 #endvote 14:12:11 Voted on "should we have, 2x 5min timeslots of the start of this meeting from now on to sunc updates from the previous Driver and Artifact meetings ?" Results are 14:12:24 #action nikhil_k : change the format of the meeting to have those time slots 14:12:57 #action all: read the logs and keep agenda of the Glance weekly meeting updated ( https://etherpad.openstack.org/p/glance-team-meeting-agenda ) 14:13:28 more? 14:14:02 #topic glance-quota-enhancements 14:14:11 thanks 14:14:13 harshs: please go ahead 14:14:20 thanks nikhil_k 14:14:28 #action harshs : create a spec for that BP 14:14:29 this is the blueprint 14:14:31 https://blueprints.launchpad.net/glance/+spec/glance-quota-enhancements 14:14:51 just wanted to know thoughts from the folks 14:14:54 #link https://github.com/openstack/glance-specs/ 14:15:13 Quotas are racy (very very racy) 14:15:27 :) 14:15:34 Plus they can be really tricky if you wanna ensure across services 14:15:40 Nova is doing some work around this 14:15:53 The idea scenario is we have a openstack wide quota lib 14:15:56 they are also really really wanted across the userspace 14:15:57 ideal* 14:16:19 nikhil_k: has there been any progress on that front? 14:16:27 harshs: we should sycn with Nova PTL to see how much traction we can get there. I think we need them 14:16:42 nikhil_k: ok. makes sense 14:16:47 mclaren: Only on abstract level. we need people for making it happen that's all :) 14:17:00 right 14:17:38 yeah I think other services eg cinder have done their own thing so I wouldn't be against us not waiting for a global thing 14:17:42 also as far as i know there isn’t still a consensus on the common quota lib front or is there? 14:17:51 are these per-user quotas? 14:18:05 mclaren: per user or per tenant 14:18:12 cool 14:18:25 mclaren:++ 14:18:32 we've waited long enough 14:18:34 would they be for v1/v2/v3 or common to all? 14:18:49 please, lets stop adding stuff to v1 :D 14:18:52 I think we don't want any more feature richness in v1 14:18:56 * flaper87 hides from mclaren's looks 14:19:13 ok, so if you want quotas you have to disable v1? 14:19:36 mclaren: I think we have to start deprecation path for v1 very soon nonethelss 14:19:45 flaper87: I do agree, but as long as v1 is the only one Nova is using, it really does not help to enforce the quotas only on the later ones :D 14:19:53 there's some buzz happeing around defcore 14:19:59 sure, just trying to understand the big picture 14:20:26 jokke_: we MUST move away from Nova using v1 this cycle 14:20:30 personally I think any quotas should be api version agnostic 14:20:37 I remember Jay Pipes's promise to switch nova to v2 at the weekend :) 14:20:42 jokke_: right but there are efforts on changing that for Liberty and as long as we keep saying: "We'll add this to v1 because nova is sitll using it" we won't ever move away from v1 14:20:53 You want quotas? Oh look, v2 has them 14:20:55 :) 14:21:00 :) 14:21:11 which gives this spec even more value 14:21:13 :D 14:21:25 mfedosin: cool! I have your writting proxy now :P 14:21:26 yeah I think that's fine. Perhaps an incentive to swifch off v1 14:21:27 but yeah, I agree they should be as agnostic as possible 14:21:31 written* 14:21:34 flaper87: ofc, as that approach has worked so well :P 14:22:01 jokke_: what do we have that v1 doesn't? Except for tasks (that require writing json on the CLI) and fewer bugs ? 14:22:05 so we target v2, but try to keep v3 in mind with the design? 14:22:07 * flaper87 won't get into the v1/v2 war now 14:22:19 +1 mclaren 14:22:25 mclaren++ 14:22:34 mclaren: you are on a roll 14:22:36 :D 14:22:41 _but_ actual details on that bp ... do we track difference between image and snapshot? I did not think so 14:22:43 harshs: please bring this up in the artifacts meeting 14:22:49 nikhil_k: sure 14:23:39 moving on 14:23:52 so regarding the actual proposal I think snapshot quotas needs to be implemented on Nova & Cinder as they actually know what the image is they are creating/uploading 14:23:59 #topic Glance-api and ceph ( mfedosin ) 14:24:11 hi, folks 14:24:12 #link https://review.openstack.org/#/c/186780/ 14:24:20 I want to discuss one thing with you about ceph backend. 14:24:38 Some time ago our QAs played with it (like switched on and off) and at some point ceph stopped to answer. 14:24:51 When they tried to upload an image there with glance, glance-api hanged with no response. 14:25:05 I figured out what it was - cinder guys had the same problem. 14:25:26 Actually two problems: 14:25:35 1. We don't have connection timeout with it. 14:25:51 https://review.openstack.org/#/c/103424 14:26:21 2. And since RBD is a python binding for librados it isn't patched by eventlet. 14:26:32 https://review.openstack.org/#/c/175555/ 14:27:02 Combination of these two issues leads to infinite hangup of glance-api, if there is no response from the ceph-server. 14:27:17 :( 14:27:22 only restart helps 14:27:30 1) I'm all up to putting timeouts on all those calls 14:27:58 I started to work on this https://review.openstack.org/#/c/186780/ 14:28:15 but it seems like we need massive refactoring of the driver 14:28:27 like creating a single method for getting a connection, because currently it happens in every method. 14:28:58 Is it okay and can you review it after it's done, because I'm not so familiar with ceph? 14:29:04 2) I think we need to address this somehow, BUT I'm not really fond of starting to spin up threads for all kind of blocking things that the current eventlet approach can't handle ... this is again one of those things that we need to add to the list adding weight to get rid of eventlet 14:29:38 == jokke_ 2) 14:29:43 mfedosin: why do you think a major rewrite is needed ? 14:30:04 flaper87, not so much actually 14:30:07 I'd like to involve rdb folks on this 14:30:31 just a single method for getting a connection 14:30:49 which works with timeout 14:30:54 flaper87, thanks! 14:30:54 mfedosin: the purpose of limiting thread size is dissolved if we create another pool 14:31:01 mfedosin: please, keep me posted and I'd like to review it 14:31:21 this needs a security eval from operators actually using rbd 14:31:42 separate threads is not necessary, it's just an improvement 14:31:44 s/thread size/thread pool size/g 14:31:55 yeah 14:32:02 mfedosin: can we start with just the timeout for now 14:32:06 I think we shouldnt' create a separate pool 14:32:09 I think it'd be better to keep these patches separate 14:32:21 just to make sure we have a "Panic Revert Exit" 14:32:22 that is clearer 14:32:30 definitely 14:32:39 okay, let's start with timeout, because second part is easy 14:32:49 mfedosin: awesome, thanks for working on this 14:32:58 I wasn't aware of this issue 14:33:06 mfedosin: do we have a way to replicate it? 14:33:11 Also I think I should file a bug in launchpad, based on the information fro the QAs 14:33:13 (that doesn't imply mocking) 14:33:20 mfedosin: please do :-) 14:33:23 until this is really evaluated I'm more than happy to -2 any patch that starts spinning up wild threads from glance ;) 14:34:00 wild threads in their natural environment 14:34:23 #topic test coverage ( agalkin ) 14:34:40 agalkin: you're not kidding! 14:34:55 okay, I will say a couple of words here 14:35:13 so, about test coverage... 14:35:21 It's very low, you know :) 14:35:28 agalkin: what feedback/help do you need from us? I think this is a good start. 14:35:36 And Alexey Galkin is eager to improve it. 14:35:53 So I think he's going to write a small etherpad document, that describes concrete steps of what will be done. 14:36:03 do we have any stats? 14:36:09 agalkin, am I right? 14:36:11 can someone tell me what is the test coverage on glance - artifacts + indexing (as in searchlight) 14:36:20 38% currently 14:36:37 mfedosin, yes you are right 14:36:57 glance - (artifacts + indexing) is 38% ? 14:37:09 I thinks these stats about v1 and v2 excluding artifacts and stuff 14:37:29 , without artifacts 14:37:29 nikhil_k, yes 14:37:51 v1 versus v2 would be interesting 14:38:14 agalkin, can you compare v1 and v2 too? 14:38:41 agalkin: would love to know more on the details of the stats. I think functional coverage might be way lower so that a big concern 14:39:03 well, I'll try 14:39:53 agalkin, thank you! please, provide as much stat information as you can in your etherpad 14:40:09 so we can discuss it on the next meeting 14:40:23 Actually one question: do we need a blueprint on this, or just etherpad + irc discussions is enough? 14:40:55 etherpad + irc 14:41:11 nikhil_k, okay, get you 14:41:33 so, that's all for now. thanks for your responses 14:41:55 #topic Open Discussion 14:42:31 mclaren: is your travel looking tentative (still) ? (for mid-cycle) 14:43:19 did we finalize a date? 14:43:34 * jokke_ is wondering what the heck our tests are testing ... glance/ -tests/ is around 49k lines and tests is around 58k lines 14:43:53 mclaren: june 28-30 14:43:58 err 14:44:04 july 28-30 14:45:01 ah, ok, thanks. 14:45:12 have we finalized a location? 14:45:49 Because we seem to have tentatively very low particiation from outside of US, and a lot!! of people wanted to have mid-cycle in Blacksburg, we will conduct there 14:46:34 nikhil_k: I may be able to make that but I'm not fussy on location at all 14:46:41 but since a lot of the active members are busy and find it hard to travel during these dates/venue and we have an incresibly tough scheduling problem 14:47:21 we will limit our decisions on the important specs unless people have good experience with video conferencing tool 14:47:36 I have chatted witht he repr there and they are willing to support the same req 14:48:14 The problem now is of time slots for important sessions/topic 14:49:01 mclaren: thanks! 14:49:19 nikhil_k: Blacksburg as in Blacksburg, Virginia? 14:49:22 ruding for you and flaper87 to join the same 14:49:32 and others who said that it was not likely (before) 14:49:40 jokke_: yes 14:50:24 nikhil_k: Washington and Atlanta being closest airports? That place looks like really interesting to get in to :P 14:50:35 Charlotte is closer 14:50:35 jokke_: CLT 14:51:17 if people are flying into CLT, I can arrange for ride-share (by someone who is attending the same) 14:52:42 nikhil_k: yeah the end half of July & August are normally bad times for Europeans as they are either on holidays or crazy busy covering someone who is on holidays on top of their own job 14:53:13 gotcha 14:53:51 I thought it would be a bad idea to postpone it beyond July considering the cycle is small 14:54:07 early in the July did not work out for a long time 14:54:43 yeah, it's a lot of folks from a lot of places to try to co-ordinate 14:55:08 nikhil_k: I'm not blaming, just stating the most probable reason for your note not seeing much attendance out of US 14:55:16 Since, we had the past couple of mid-cycle in summer during this period, I figured it might be a good possiblity. 14:55:41 nikhil_k: what's the defcore buzz you mentioned earlier? 14:55:55 jokke_: gotcha. Thanks, I am a little fried and burned by this scheduling experience :P 14:56:25 mclaren: the problem is that people want a single API that needs to be supported for a really long time 14:56:35 something that can't be deprecated (forever) 14:56:47 people are asking which is that API 14:57:01 yeah 14:57:03 plus we moved v1 to supported and v2 to current now 14:57:12 Nova still needs v1 14:57:25 that can be confusing for operators who have upgraded to kilo 14:57:42 on top of that 14:57:48 we have 2 ways to do upload and downloads 14:58:09 nikhil_k: wasn't it just v1 from current to supported? IIUC both of them were stated as current for long time 14:58:10 so the tempest tests for defcore need to pass for all clouds on that sigle API defined necessary for interop 14:58:41 jokke_: it's just our plan for moving away from supported that's confusing 14:59:03 I guess a v3 adds to the buzz? 14:59:13 moving away from supported == deprecating the API 14:59:25 not at this point 14:59:29 but could be 14:59:39 it's the tasks that is the problem, actually 14:59:50 I think the problem becomes if v3 starts to support images at some point 15:00:19 the wrapping of the v2 APi on top of v3 can help with that 15:00:32 if we get nova, cinder, horizon using v2 and kick v1 out, I think defcore would be perfectly happy to be told that that is de facto images api 15:00:49 nikhil_k, we're thinking about that 15:00:53 jokke_: +1 on nova, cinder, horizon using v2 15:01:04 kicking out v1 would be tricky but possible 15:01:16 thanks mfedosin 15:01:35 Ok, we are out of time 15:01:39 Thanks all! 15:01:44 thanks! 15:01:44 #endmeeting