14:00:13 <nikhil> #startmeeting glance
14:00:16 <openstack> Meeting started Thu Jun  2 14:00:13 2016 UTC and is due to finish in 60 minutes.  The chair is nikhil. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:19 <openstack> The meeting name has been set to 'glance'
14:00:20 <kairat> o/
14:00:23 <tsymanczyk> \o
14:00:23 <nikhil> #topic roll call
14:00:24 <bpoulos> o/
14:00:31 <mfedosin> o/
14:00:39 <abhishekk> o/
14:00:44 <wxy1> o/
14:00:46 <nikhil> welcome all
14:00:49 <nikhil> let's get started
14:00:51 <nikhil> #topic agenda
14:00:55 <croelandt> o/
14:01:00 <nikhil> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:01:02 <dshakhray> o/
14:01:14 <bunting> o/
14:01:20 <nikhil> I have set up a few items on tuesday that struck me worth discussing , earlier in the week
14:01:21 <jokke_> o/
14:01:36 <nikhil> but we can substitute those items for anything more important that comes up
14:01:50 <nikhil> #topic Updates
14:02:03 <nikhil> #info Glare updates ( mfedosin )
14:02:12 <mfedosin> hey!
14:02:35 <mfedosin> so, we're testing Glare
14:03:00 <mfedosin> it seems, like all things are done
14:03:19 * nikhil hears great news, starts dancing
14:03:21 <mfedosin> and next week we'll start preparing the code for review
14:03:42 <mfedosin> we're going to spend 3 days on that
14:03:51 <mfedosin> wed-fri
14:04:21 <mfedosin> so, next Friday you'll be able to start reviewing it
14:04:52 <nikhil> great
14:04:55 <mfedosin> also, last week generics types were implemented
14:05:26 * jokke_ orders beer & popcorn. Time to flex the -2 finger :P
14:05:27 <mfedosin> and you can define dictionary property as Dict + element_type
14:05:50 <mfedosin> before you had to define your own type
14:05:59 <mfedosin> like DictOfStrings
14:07:01 <nikhil> all this needs good documentation otherwise we will have problem of lack of shared understanding
14:07:02 <mfedosin> I got several comments on the spec
14:07:08 <jokke_> mfedosin: so is this now the final experimental API or is this considered as stable?
14:07:22 <mfedosin> jokke_: it will be experimental
14:07:30 <mfedosin> initially
14:07:47 <jokke_> Like Stable candidate :)
14:08:00 <mfedosin> rc1 if you want :)
14:08:26 <mfedosin> after that we'll start integrating Glare in Murano and Heat
14:09:00 <mfedosin> and if it requires (I hope not) we'll make changes based on their feedback
14:10:04 <mfedosin> I thinks that's all Glare updates
14:10:08 <nikhil> thanks
14:10:11 <nikhil> #info Nova v1, v2  (mfedosin, sudipto)
14:10:30 <nikhil> I guess we are still waiting no reviews
14:10:43 <mfedosin> I finished porting Xenapi plugin
14:10:45 <mfedosin> https://review.openstack.org/#/c/324536/
14:11:05 <mfedosin> and yeah - we're waiting for reviews
14:12:05 <nikhil> ok, any blockers?
14:12:15 <jokke_> mfedosin: that xenapi plugin was the last bit to provide them the functionality, right now it's just matter of reviews and merge?
14:12:37 <mfedosin> frankly speaking, we also have hyper-v
14:12:53 <mfedosin> and for some reason it fails several tests if v2 is enabled
14:13:21 <mfedosin> I hope I'll fix'em today, based on logs
14:13:38 <mfedosin> other things work pretty fine
14:13:44 <nikhil> Thanks mfedosin
14:13:46 <jokke_> nnice
14:13:57 <nikhil> Let's make sure we sync with nova team upcoming monday
14:14:11 <mfedosin> jokke_: (they did in February)
14:14:17 <nikhil> their target was mid-june and many reviews are ready for review
14:15:05 <nikhil> mfedosin: great, any more updates?
14:15:14 <mfedosin> nope :)
14:15:18 <nikhil> Thanks again
14:15:20 <nikhil> #topic Releases (nikhil)
14:15:23 <mfedosin> welcome
14:15:30 <nikhil> so, newton-1 is released
14:15:37 <nikhil> #info glance newton-1 https://review.openstack.org/#/c/323533/1
14:16:04 <nikhil> #info I plan to propose a client and store release later this week
14:16:36 <nikhil> but release team is reluctant on releasing those in the later half of the week so we cannot expect them to be out until early next.
14:16:44 <jokke_> ++
14:16:51 <jokke_> never good idea to release at Fri
14:17:08 <nikhil> :)
14:17:10 <nikhil> newton-2 has begun
14:17:30 <nikhil> so, let's make sure out important specs, esp. lite-specs are done in this timeframe
14:17:42 <nikhil> if something is slow, feel free to flag the author that it is so
14:18:17 <nikhil> same goes for reviews, if there's -1 for long time (>1 week) please feel free to ping the reviewer and move on if no response
14:18:30 <nikhil> that's it on releases
14:18:38 <nikhil> #topic Announcements (nikhil)
14:18:48 <nikhil> #info annoucement/poll for virtual mid: http://lists.openstack.org/pipermail/openstack-dev/2016-May/096180.html
14:19:01 <nikhil> I got one response back on the email about them attending
14:19:16 <nikhil> rest of you please say either +1, 0, -1
14:19:24 <nikhil> by default your vote goes as +1
14:19:39 <nikhil> Also, note:
14:19:42 <nikhil> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/096175.html
14:19:52 <nikhil> our soft freeze is due soon
14:20:04 <nikhil> I've posted comments on the glance-specs indicating to the author about the dates
14:20:22 <nikhil> if there are new specs and you think authors may be unaware then feel free to add the comment indicating the same
14:21:13 <nikhil> that's it here
14:21:30 <nikhil> #topic Lite-specs final discussion for newton (nikhil)
14:22:16 <nikhil> So, i wanted to finalize the process this week
14:22:38 <nikhil> We have one lite spec merged
14:22:49 <nikhil> but I can move that as required
14:23:37 <nikhil> I had some feedback from hemanth and jokke_
14:23:53 <nikhil> but if there are no serious issues, I can either talk to flaper87 and get this resolved
14:24:07 <nikhil> if you have opinion please add a comment on https://review.openstack.org/#/c/315339/
14:24:18 <nikhil> basically, a few things are important:
14:24:23 <jokke_> 'm still against of turning the process around in the middle of the cycle
14:24:38 <nikhil> 1. we need a way to restrict lite-specs a few weeks before newton-3
14:24:44 <nikhil> jokke_: currently there's no process
14:25:02 <nikhil> and the email I sent to ML was the indication of process
14:25:38 <nikhil> (I am sort of disapppointed about all the issues not raised then and delay already)
14:26:09 <nikhil> So, this is the last week and I will ninja approach otherwise
14:26:22 <nikhil> thanks
14:26:26 <mfedosin> sorry for dumb question... what's the difference between lite-specs and release notes?
14:26:56 <nikhil> good stuff for documentation
14:27:04 <nikhil> (third time, this is being asked)
14:27:21 <nikhil> mfedosin: refer this for initial feedback http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-05-05-14.00.log.html#l-48
14:27:52 <mfedosin> it was semi-rhetorical question :)
14:28:14 <nikhil> mfedosin: then it's not a dumb question in the first place
14:28:28 <nikhil> mfedosin: if you WANT TO KNOW MORE read up the need for lite-spec here: http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-05-19-14.00.log.html#l-155
14:29:06 <nikhil> #topic Specs
14:29:10 <mfedosin> nikhil: gotcha thanks
14:29:32 <nikhil> #info Upgrades & registry
14:29:48 <nikhil> unfortunately, a lot of this discussion is happening without all stakeholders participating
14:30:03 <nikhil> again something I may ninja approve if people give last minute -1s, -2s
14:30:19 <nikhil> good place to refer:
14:30:23 <nikhil> https://review.openstack.org/#/c/299726/
14:30:32 <nikhil> https://review.openstack.org/322712
14:31:09 <mfedosin> nikhil: but we can't deprecate registry, while glance v1 is still supported
14:31:18 <nikhil> We need the right story to guide us to either deprecate the registry or tell us if we can asset tag for rolling upgrade or what more needs done.
14:32:07 <nikhil> Hemanth mentioned he was working on the research -- what other projects are doing in openstack. That may help.
14:32:36 <nikhil> But a lot of the upgrade stories are subjective to the deployments, something that I may bring up in the ops sync next week (if that happens).
14:32:46 * jokke_ agrees with flaper87 that us keeping registry and having rolling upgrade has no common factor
14:34:14 <nikhil> jokke_: then you are welcome to give the detailed feedback on the above review (299726) indicating why. Michal seems to indicate the need for conductor like service or I may have mis-interpret that. Either way, shared understanding should be our goal.
14:34:15 <jokke_> we need implement any plans for rolling upgrades for API-db communications anyways as that's supported model in v2 and apprently the more used one
14:35:01 <nikhil> I do not find that as enough indicator to take the decision either way.
14:35:17 <nikhil> We need the How-s, Why-s and What-s on upgrades.
14:35:54 <nikhil> #info glance_store & image_props
14:36:08 <nikhil> #link https://review.openstack.org/323260
14:37:01 <nikhil> There's something holding me back on -2 such proposals... and that is I care about our volumes-stakeholders
14:37:52 <nikhil> if you represent one of that groups, please provide feedback ASAP,
14:38:24 <nikhil> there's only a little time in newton to accept any more proposals and if they are conceptual changes, there's not enough bandwidth to do the research.
14:38:48 <nikhil> I'm assuming there's no feedback here.
14:38:55 <nikhil> moving on
14:39:14 <nikhil> #info Race conditions on properties: good-s vs. bad-s
14:39:21 <nikhil> #link https://review.openstack.org/#/c/315483/
14:39:36 <nikhil> SO, there are two things in that spec
14:39:38 <mfedosin> dshakhray: it's yours :)
14:39:48 <nikhil> #1. the scope of transactional semantics are not defined
14:39:57 <nikhil> that's the reason why a straight away -1 from Jay
14:40:18 <nikhil> for example, the transaction layer won't help with race conditions when:
14:40:27 <nikhil> a) there are 1M PATCH requests
14:40:39 <mfedosin> why?
14:40:44 <nikhil> b) there are 100K PATCH requests
14:40:56 <nikhil> c) may be in some cases there are 1k PATCH requests
14:41:04 <nikhil> that include C, U & D operations
14:41:12 <nikhil> the input for each of these request is consistent
14:41:29 <nikhil> but the output will always be variable because the atomiticity is built in the DB layer
14:41:55 <nikhil> and the transaction layer is merely isolating two separate calls and does not gurantee the sequence of them
14:42:11 <nikhil> so, we have to use the work 'transaction' carefully
14:42:12 <kairat> So
14:42:13 <mfedosin> nikhil: but do we need this gurantee?
14:42:20 <nikhil> ^
14:42:25 <kairat> That's REST)
14:42:38 <nikhil> word*
14:42:50 <mfedosin> no, I mean if two users want to update name at one time...
14:42:51 <nikhil> and pythong
14:43:05 <nikhil> python*
14:43:19 <mfedosin> they both send request, one updates first, another is second
14:43:59 <mfedosin> the second user just rewrites first value
14:44:22 <nikhil> yep, the sequence of those calls is not transactional
14:44:58 <nikhil> that has more than one element to it 1. eventlet 2. python 3. REST ...
14:44:59 <mfedosin> nikhil: I think we need to talk more on that matter
14:45:01 <jokke_> so as long as we don't implement locks and start to be really bitchy about this, we will never get rid of all races
14:45:13 <nikhil> jokke_: correct
14:45:20 <jokke_> but what dshakhray and mfedosin are proposing at least limits the scope quite a bit
14:45:40 <kairat> It at least guarantees what only changes will be applied to db
14:45:44 <kairat> and nothing more
14:45:55 <jokke_> it limits the scope of the races only to the same keys that has been changed in multiple places
14:46:02 <mfedosin> jokke_: and also optimizes db insertions
14:46:16 <nikhil> sure, that the point #2. limit the transactional gurantee of that layer
14:46:21 <jokke_> mfedosin: that's database voodoo for me :P
14:46:48 <nikhil> Let's not call it transactional layer
14:46:54 <jokke_> mfedosin: but I do understand the logic of updating only changes, not the whole state+changes when the change started
14:47:08 <nikhil> because there's a lot more to transactions than just preventing isolation from two separate API calls
14:47:24 <mfedosin> nikhil: how do you prefer to call it?
14:47:32 <jokke_> Blue
14:47:55 <jokke_> Purple would do as well, but definitely not yellow
14:48:01 <nikhil> it can be isolation layer or may be something along that lines
14:48:23 <mfedosin> nikhil: okay, we'll think about it
14:48:32 <nikhil> mfedosin: this is my feedback to help prevent -1 from the experts like Jay (who is right on target there)
14:49:24 <nikhil> also, I wanted to bring this up as mfedosin mentioned to me that this spec is related to the academic completion for dshakhray
14:49:26 <jokke_> nikhil: are we talking about the same thing?
14:49:39 <nikhil> so early feedback to her will only help
14:49:46 <jokke_> Only comment I see from Jay is just preventing updates during saving
14:49:56 <jokke_> as alternative
14:50:31 <mfedosin> Jay wants to deprecate any image updates if status is saving
14:50:46 <mfedosin> I think it's not a good solution
14:50:47 <nikhil> jokke_ there is some email that mentions about not writing transcations in python
14:50:52 <jokke_> mfedosin: ++
14:51:08 <kairat> it is not compatible
14:51:18 <nikhil> v1 and v2 do not need to be compatible
14:51:24 <nikhil> (fyi)
14:51:50 <jokke_> nikhil: ++ that's why it's called Major version change :D
14:52:04 <nikhil> ;)
14:52:06 <nikhil> anyway, we can continue this in open discussion. but I want to give others a chance to ask questions..
14:52:13 <nikhil> #topic open discussion
14:52:15 <jokke_> mut I still don't think it's a fgood idea
14:52:28 <nikhil> I never said good or bad about it
14:52:36 <nikhil> (specifically)
14:52:49 <mfedosin> thanks for feedback
14:52:58 <kairat> nikhil, I was not talking about v1 and v2
14:53:00 <mfedosin> Darja will update the spec soon :)
14:53:00 <kairat> but
14:53:06 <kairat> let's move discussion to spec
14:53:23 <kairat> How about expiring old bugs
14:53:28 <kairat> in glance?
14:53:31 <nikhil> kairat: yeah, I get it. I (too) mentioned it's not backwards compat.
14:53:40 <nikhil> kairat: oh heck yes!
14:54:00 <nikhil> let's get a bug day going ?
14:54:01 <mfedosin> so, today I mentioned that hyper-v doesn't work with v2... I found the reason
14:54:06 <kairat> Previsouslu I periodically reviewed bugs
14:54:16 <nikhil> June 13th?
14:55:19 <kairat> We can do that
14:55:21 <mfedosin> in v1 we have purge_props flag, that removes all unspecified properties and it's True by default https://github.com/openstack/nova/blob/master/nova/image/glance.py#L413
14:55:33 <kairat> but I was talking about solution like this: [openstack-dev] [nova] I'm going to expire open bug reports older than 18 months.
14:55:37 <kairat> WDYT?
14:56:02 <nikhil> #startvote Would you like Glance to have bug day on June 13, 2016? (yes, no, maybe)
14:56:02 <openstack> Begin voting on: Would you like Glance to have bug day on June 13, 2016? Valid vote options are , yes, no, maybe, .
14:56:03 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
14:56:07 <mfedosin> but if we provide properties as empty dict, then this flag is ignored. Hyper-v use this feature (or bug)
14:56:08 <nikhil> #vote yes
14:56:16 <mfedosin> #vote yes
14:56:19 <bunting> #vote yes
14:56:28 <kairat> June 13 is holiday in Russia
14:56:31 <kairat> mfedosin, ^
14:56:45 <tsymanczyk> #vote yes
14:57:02 <kairat> Ok, will try  also
14:57:07 <kairat> #vote yes
14:57:11 <nikhil> We can try June 13 and 14
14:57:13 <jokke_> #vote maybe
14:57:19 <nikhil> and we can let people choose
14:57:26 <mfedosin> kairat: ouch
14:57:28 <nikhil> it's not like people are co-located
14:57:34 <nikhil> #endvote
14:57:34 <openstack> Voted on "Would you like Glance to have bug day on June 13, 2016?" Results are
14:57:36 <openstack> maybe (1): jokke_
14:57:37 <openstack> yes (5): bunting, mfedosin, nikhil, kairat, tsymanczyk
14:58:15 <nikhil> kairat: I think that's a good idea in general. I am curious who would like to maintain that process?
14:58:52 <nikhil> kairat: Can we assume you will have b/w to do that over time? or are you suggesting one time thing?
14:58:55 <kairat> Ok, I will try to lead that next week
14:58:58 <jokke_> perhaps we need liaison or workgroup for that :P
14:59:11 <kairat> I suggest to clean it first
14:59:16 <nikhil> we've shortage of people already
14:59:26 <bunting> I think on the bug days, its probably worth having a etherpad with priorities
14:59:40 <nikhil> kairat: To be 'really' honest, what we need a clean up of specs more than of old bugs
14:59:49 <nikhil> at least for the next couple of weeks
14:59:51 <jokke_> nikhil: IIRC the original proposal for nova was including scripting that talks with the LP api and does it, not manual labor
15:00:16 <nikhil> ok
15:00:23 <kairat> jokke_, yep, that's good option
15:00:26 <kairat> no manual work
15:00:37 <nikhil> Let's discuss that a bit more on -glance
15:00:57 <nikhil> we're out of time today
15:01:06 <kairat> Ok, thanks
15:01:07 <jokke_> thanks all
15:01:10 <nikhil> I'm available to chat on -glance for a bit for any outstanding questions from this meeting
15:01:15 <nikhil> Thanks all.
15:01:18 <nikhil> #endmeeting