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