15:02:02 <nikhil_k> #startmeeting Glance
15:02:03 <openstack> Meeting started Thu Dec 11 15:02:02 2014 UTC and is due to finish in 60 minutes.  The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:05 <kragniz> o/
15:02:06 <openstack> The meeting name has been set to 'glance'
15:02:07 <pennerc> o/
15:02:16 <nikhil_k> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
15:02:41 <nikhil_k> #topic Mini-summit details
15:02:42 <mclaren> \o
15:02:52 <nikhil_k> #link https://etherpad.openstack.org/p/kilo-glance-mid-cycle-meetup
15:03:39 <nikhil_k> #info Glance mid-cycle meetup for Kilo will be at the VMware office in Palo Alto on Jan 27, 28 parallel to Nova in a separate room for 32
15:04:16 <nikhil_k> Please indicate your tentative/planned participation for the same in the next couple weeks or so
15:04:17 <flaper87> FWIW, we should try to avoid organizing meetups in the west-coast
15:04:27 <flaper87> it's way too expensive for a 2 days mini-conf
15:04:43 <flaper87> and this doesn't mean I'm not thankful for the location
15:04:48 <flaper87> and the organization
15:04:48 <jokke_> flaper87: next one is at West-Coast as well, but much closer (hopefully) ;)
15:04:49 <nikhil_k> that will help the event planners to conduct the event smoothly
15:05:04 <zhiyan> hi (sorry for late)
15:05:36 <nikhil_k> the intent of the email to the active developers was to figure out if it would work out or not
15:05:53 <nikhil_k> unfortunately, scheduling is difficult for larger groups
15:06:23 <nikhil_k> I'd preferred to have this on east coast however, the majority said otherwise
15:06:23 <flaper87> jokke_: :P
15:06:40 <nikhil_k> so, we will just go with it for now
15:07:07 <jokke_> nikhil_k: I think the joint meetup with Nova was the big driver ... inconveniences
15:07:08 <flaper87> yup, ok.
15:07:12 <nikhil_k> #info Please add topics to be discussed at the mid-cycle meetup to the etherpad
15:07:17 <flaper87> can we make sure we have a way to attend remotely ?
15:07:33 <nikhil_k> we can try
15:07:48 <nikhil_k> #action ask event planner to arrange for remote participation
15:08:09 <nikhil_k> #topic k1
15:08:16 <zhiyan> i'd like to help try it from remote if needed
15:08:27 <cpallares> me too
15:09:23 <nikhil_k> ok, have created another topic in the etherpad for remote participation
15:09:38 <nikhil_k> we can try to schedule the topics accroding to the interest and timezone
15:09:41 <nikhil_k> please add the info
15:09:49 <nikhil_k> #info k1 to be cut between Dec 16 and Dec 18
15:09:50 * flaper87 will do that
15:10:10 <nikhil_k> #link https://launchpad.net/glance/+milestone/kilo-1
15:10:26 * flaper87 will focus on reviews
15:10:39 <flaper87> we're not doing that bad  except for the review backlog
15:10:43 <flaper87> at least patches are up
15:10:44 <nikhil_k> #info cores and the drivers please try to focus reviews on the k1 BPs/bugs
15:11:18 <nikhil_k> #action nikhil_k , rosmaita and arnaud : to review and approve the necessary specs to land the code
15:11:28 <nikhil_k> we can try to get 2-3 BPs if not all
15:11:56 <flaper87> nikhil_k: we should also start doing that for k-2 specs too
15:12:11 <nikhil_k> have re-prioritized the BPs so that we can forcus on a few
15:12:25 <nikhil_k> please let me know if you've concerns
15:12:46 <nikhil_k> flaper87: sure thing. The plan is to approve all the kilo specs in the next 3 weeks
15:13:06 <nikhil_k> that way the scheduling and approval is not much of a problem
15:13:29 <flaper87> nikhil_k: I'll help with that
15:13:45 <nikhil_k> sounds good.
15:13:58 <nikhil_k> #info everyone: please try to review the specs
15:14:19 * nikhil_k waits to see if there are any more concerns
15:14:44 * flaper87 sips coffee
15:14:48 <jokke_> nikhil_k: all of the ones left targeting for k1 are something that are ready to land in time?
15:15:09 <nikhil_k> that is the hope
15:15:15 <jokke_> nikhil_k: or is there panic expected? :P
15:15:32 <nikhil_k> the most ready 2-3 BPs should be able to land
15:15:52 <nikhil_k> no panic, we will do this smoothly
15:15:58 <nikhil_k> and skip k1 if not possible
15:16:06 <nikhil_k> and come up with a more proactive plan for k2
15:16:15 <jokke_> ++
15:16:19 <zhiyan> > "The plan is to approve all the kilo specs in the next 3 weeks" ,really like a good idea
15:16:41 <flaper87> :P
15:16:53 <nikhil_k> next up....
15:16:58 <nikhil_k> #topic stable maint group for Glance
15:17:19 <nikhil_k> so, there is a plan to create the group if it's not already created
15:17:30 <nikhil_k> #action nikhil to check the status
15:17:44 <nikhil_k> #info jokke_ and nikhil_k are in the stable maint group atm
15:17:51 <flaper87> I'm in the global openstack stable-maint group, I would love to keep doing this for glance
15:17:55 <nikhil_k> we will have more people once things are finalized
15:18:06 <nikhil_k> flaper87: sg
15:18:13 <flaper87> in other words, I've already -2 powers on all those patches :P
15:18:35 <nikhil_k> we will undoubtedly benefit from your expertise
15:18:47 <cpallares> lol
15:19:13 <nikhil_k> that basically solves the confusion about what's happening to the stable/incehouse etc PRs
15:19:15 <jokke_> flaper87: that means no breaking client nor glance_store until we get stable out of those as well :P
15:19:28 <nikhil_k> contact the stable team if you think that the patch can land
15:19:51 <nikhil_k> stable team will collaborate with you to see if the patch fits the criterion or if exception can be granted
15:19:58 * flaper87 breaks nothing
15:20:12 * nikhil_k waits
15:20:23 * jokke_ hides
15:20:31 * flaper87 scares jokke_
15:21:11 <nikhil_k> #topic fast-track after k1
15:21:35 <nikhil_k> it's not a possibility with the current setup in launchpad
15:21:51 <nikhil_k> so, if anyone has energy to do this please come up with a creative idea
15:22:10 <jokke_> could you define fast track in the context?
15:22:14 <nikhil_k> else my plan is to prioritize the specs/BPs and send emails to the respective groups
15:22:31 <nikhil_k> okay, so the terminology is a bit confusing
15:23:26 <nikhil_k> fast-track == a small focused sprint like week or two. focus around important BPs/bugs that did not land in k1 and can merge soon-ish
15:23:49 * nikhil_k waits
15:23:49 <flaper87> nikhil_k: I'd probably do that closer to the end of k-2
15:23:55 <jokke_> ah
15:24:01 <flaper87> just to know if we need to fast-track k-2 bps
15:24:08 <flaper87> before the FF
15:24:13 <nikhil_k> we need to flaper87
15:24:25 <nikhil_k> as we are gunna have a informal freeze 2 weeks after k2
15:24:55 <kragniz> how formal will this informal be?
15:24:59 <zhiyan> can we define some sub/small milestone in LP, and set suitable bug to it? (iiuc the terminology)
15:25:00 <flaper87> kk
15:25:37 <nikhil_k> zhiyan: the weird thing is it will create confusion for other projects or openstack as a whole
15:25:43 <nikhil_k> so we cannot do this in LP
15:26:03 <nikhil_k> core members need to be vigilant and communicate on the patch sets accordingly
15:26:05 <jokke_> ah LP <3
15:26:12 <flaper87> jokke_: >.>
15:26:14 <zhiyan> nikhil_k: if so, seems to maintain a list in a etherplad is a idea?
15:26:29 <nikhil_k> zhiyan: that sounds like a good idea
15:26:44 <jokke_> nikhil_k: so auto -2 on everything and then we look exceptions? :P
15:26:45 <nikhil_k> we will see closer to the freeze
15:26:49 <zhiyan> nikhil_k: can we list security related bug into it?
15:26:55 <nikhil_k> kragniz: pretty formally informal
15:27:00 <zhiyan> ok, should be ok, due to LP right
15:27:11 <nikhil_k> (and not informally formal)
15:27:25 <kragniz> nikhil_k: makes sense :P
15:27:37 <nikhil_k> hush
15:27:39 * nikhil_k glad
15:27:48 <flaper87> +1
15:27:50 <nikhil_k> zhiyan: hmm, not sure
15:28:09 <nikhil_k> zhiyan: security bugs has a way to get exceptions so that does not seem necessary
15:28:10 <zhiyan> actually, i think it's helpful for developer, a workitem list in near term, to me at least
15:28:16 <nikhil_k> let's keep them separate
15:28:25 <nikhil_k> zhiyan: abs
15:28:33 <zhiyan> nikhil_k: ok, not sure
15:28:52 <nikhil_k> in the next week or so, am planning to come up with specs/BPs, bugs and core-to-specs mapping
15:29:15 <nikhil_k> as well as a etherpad for the convenience
15:29:52 <nikhil_k> #topic Client inconsistencies
15:29:55 * jokke_ has been using trello now for 3 days and would vote for that over etherpad
15:30:03 <kragniz> +1 for trello
15:30:16 <nikhil_k> jokke_: kragniz sure
15:30:23 <nikhil_k> not sure who proposed this topic
15:30:28 <jokke_> o/
15:30:55 <flaper87> o/
15:31:35 <flaper87> jokke_: introduce your concern, I'll go after you
15:32:09 <nikhil_k> so the API is not returning items and the client does
15:32:16 * nikhil_k not like
15:32:56 <jokke_> ok, so first step was to get our Image API server returning None valued fields which is fine, now latest proposal from flaper87 was to get the client generating those None fields for the API Servers that does not return them
15:33:26 <flaper87> So, the API now returns None fields
15:33:35 <mclaren> nit: the server returns null rather than None I think
15:33:40 <flaper87> this will require us to bump the server API version
15:33:42 <jokke_> I see the pain where this is coming from, but IMHO it's just fundamentally wrong that we assume and generate image data in the client just to be consistent with the new API functionality
15:33:42 <nikhil_k> ah ha
15:33:49 <flaper87> it returns null which is None
15:33:55 <flaper87> wait
15:34:11 <flaper87> we're not assuming anything, we *know* for sure which fields are not being returned because they are None
15:34:20 <flaper87> That's what the list of fields in that patch is for
15:34:46 <flaper87> the reason I'm doing this is because I think adding those fields to the "auto-generated" image object is far better than having inconsistent image objects
15:35:11 <flaper87> The patch adds a forward-compatible layer for consumers of glanceclient to the yet-to-be-released glance v2.3
15:35:16 <jokke_> flaper87: we are assuming as the server did not return them, we do not know if there was a bug and a field missing etc. We just assume that it's None because it was not returned
15:36:13 <jokke_> So wanted to get this discussion for wider audience to get the consensus
15:36:28 * nikhil_k agrees with jokke_
15:36:44 <flaper87> The patch is backwards compatible and it won't break client's code unless they rely on the field not being there
15:36:44 <mclaren> can you give an example of real world pain with the current behaviour?
15:36:51 <flaper87> mclaren: nova
15:37:09 <flaper87> there's a whole bunch of utility functions to *add* those fields
15:37:20 <flaper87> because in a normal environment you expect them to be there
15:37:29 <flaper87> and the fact the server didn't return those is *wrong*
15:37:51 <flaper87> I avoided all kind of magic to make this patch behavior predictable
15:38:22 <mclaren> Any reason nova can't do a image.get('prop')?
15:38:45 <mclaren> to handle old behaviour (which it needs to do I think) as well as newer behaviour?
15:39:17 <flaper87> that's just yet-another-workaround on users of glanceclient
15:39:23 <flaper87> for something that is wrong in glanceclient
15:39:48 <flaper87> Also, if you do .get('prop') you don't know if the prop is None or missing
15:40:04 <mclaren> same if you auto fill it in, right?
15:40:10 <flaper87> we'd basically be moving the "assumption" to the consumer of the library
15:40:16 <nikhil_k> why can't this be handled in the wrapper in nova?
15:40:17 <flaper87> mclaren: no because we *control* the client
15:40:24 <mclaren> but nova dont'
15:40:24 <flaper87> we know what fields can be None in the server
15:40:33 <flaper87> mclaren: control as in we develop it
15:40:51 <jokke_> flaper87: we do not move it there, we keep it there as they have taken the responsibility to assume so until now as we have never returned those fields, right?
15:40:54 <flaper87> users of the library shouldn't care on whether a field is missing because it's None in the server
15:41:09 <nikhil_k> we cannot assume everyone using the server is using the client
15:41:12 <flaper87> jokke_: but that's wrong
15:41:18 <mclaren> I think nova populate other properties, like arch, which may or may not be present, we don't control those
15:41:26 <flaper87> the whole point if to fix those things we've pushed to glanceclient's users
15:42:05 <nikhil_k> glanceclient is a tool to use glance
15:42:16 <nikhil_k> and not something that is necessary to use it
15:42:49 * flaper87 is not sure if nikhil_k last sentence is in favor or against the proposed patch
15:42:51 <flaper87> :P
15:42:56 <kragniz> nikhil_k: but it should make using glance easy, right?
15:43:14 <flaper87> I think bringing consistency to the client is something that we should do
15:43:22 <jokke_> kragniz: I would not open that can of worms :P
15:43:29 <nikhil_k> kragniz: without breaking the response
15:43:37 <kragniz> jokke_: :P
15:43:41 <nikhil_k> this may affect users who are using the client
15:43:47 <flaper87> nikhil_k: the patch is not breaking the response, fWIW
15:43:48 <jokke_> flaper87: the client is consistent with the server as it should be
15:44:16 <flaper87> jokke_: yes but it is inconsistent in the way it interacts with the user
15:44:22 <flaper87> which one do we value more ?
15:44:48 <jokke_> flaper87: well we can revert the returning None and consistently not return them from client ;P
15:45:03 <flaper87> that adds inconsistent responses
15:45:09 <flaper87> we're still breaking consistency for the user
15:45:19 <flaper87> therfore we're adding frustrations to the consumer of the library
15:45:32 <mclaren> returning null in v2 is inconsistent with v1 which doesn't return the field at all!
15:46:36 <flaper87> yeah but we can't change v1 anymore
15:46:56 <flaper87> this is about making our currently supported version consistent
15:47:07 <nikhil_k> flaper87: can we see the nova patch?
15:47:40 <flaper87> https://github.com/openstack/nova/blob/master/nova/image/glance.py#L533-L575
15:48:23 <flaper87> that's just one part
15:48:31 <flaper87> there are more things related to this in that same module
15:48:53 <nikhil_k> flaper87: well , am curious what approach is planned in nova
15:49:14 <flaper87> nikhil_k: I want to get rid of that function, entirely
15:49:21 <nikhil_k> understandably there are a lot things in the nova.image module which can be reduced
15:49:42 <flaper87> nikhil_k: you'd be surprised that most of those things exist because we are not consistent
15:49:47 <flaper87> and we've broken things for them
15:49:57 <flaper87> I'm working on removing glance.py entirely
15:50:19 <flaper87> but I've been forced to copy many of those ugly functions because *we* have a client that doesn't always work as expected
15:50:30 <flaper87> lets forget about the differences between v1 and v2, that's fine
15:50:36 <flaper87> major versions, blah blah...
15:50:49 <zhiyan> seems that function need to be there anyway, due to it works for v1 as well...
15:50:50 <flaper87> but seriously, there are other parts that could be definitely better
15:50:57 <mclaren> that nova function creates a dict from a warlock object
15:51:11 <flaper87> zhiyan: it being needed for v1 is very different than it needed for both
15:51:11 <mclaren> (in the case of v2)
15:51:56 <flaper87> we've 10 mins left, I'd really love to get this patch in the next glanceclient release.
15:52:03 <flaper87> if folks think it shouldn't be there, fine.
15:52:12 <nikhil_k> ok, so this seems to be eveloving into a bigger conversation
15:52:16 <flaper87> but lets decide so I can move ahead and I guess I'll copy that code
15:52:40 <nikhil_k> flaper87: lets avoid it for now
15:52:50 <nikhil_k> #topic Glance client release
15:53:01 <zhiyan> anyway, it will be ugly until v1 get deprecated.
15:53:17 <flaper87> zhiyan: sure but at least I can start cleaning up the v2 path
15:53:27 <nikhil_k> please ping, kragniz flaper87 jokke_ sigmavirus24_awa or nikhil_k if you would like to get your patch in a client release
15:53:29 <flaper87> nikhil_k: can we please add comments and votes on the review?
15:53:32 <mclaren> zhiyan: +1
15:54:01 <nikhil_k> #info ping kragniz flaper87 jokke_ sigmavirus24_awa or nikhil_k if you would like to get your patch in a client release
15:54:07 <nikhil_k> #topic Open Discussion
15:54:23 <kragniz> nikhil_k: are you still planning on doing the client release today?
15:54:23 <zhiyan> quick one:
15:54:32 <kragniz> or push it back more
15:54:50 <nikhil_k> oh, glad your reminder kragniz
15:54:58 <nikhil_k> would like to release the client today
15:55:17 <nikhil_k> so that we are not releasing it on Friday unless people are okay waiting until Monday
15:55:29 <nikhil_k> reminded*
15:55:44 <kragniz> okay
15:55:51 <zhiyan> do we have a glance trello account? i can't open https://trello.com/b/GFXMXxsP/openstack-glance
15:56:07 <jokke_> I think TravT_ is waiting quite eagerly for the new client to fix horizon stuff, no?
15:56:07 <nikhil_k> nope
15:56:09 <nikhil_k> it's private
15:56:15 <kragniz> zhiyan: you need to be invited
15:56:28 <nikhil_k> to avoid chaos
15:56:43 <nikhil_k> however, if you are willing to maintain it
15:56:45 <jokke_> so to get that to k1, I'd vote to ship client out today
15:56:47 <TravT_> jokke_: yeah, I can't push on horizon until we get that patch through
15:56:50 <nikhil_k> then you could be invited
15:57:46 <TravT_> actually devstack is broken right now for v2
15:57:51 <TravT_> until the client is released
15:57:59 <zhiyan> nikhil_k: if we going to use trello to maintain near term workitem as we mentioned above, i need to join it, if we like to go that way instead of etherpad
15:59:07 <jokke_> so I think everything else but the PS discussed above has landed to client from the list
15:59:12 <nikhil_k> zhiyan: you can join for sure using your user/pass combination. then you can be invited into a trello board
15:59:32 <nikhil_k> zhiyan: let's see how things go..
15:59:41 <jokke_> zhiyan: just ping nikhil with your trello username
15:59:50 <zhiyan> nikhil_k: Zhi Yan Liu
16:00:02 <flaper87> zhiyan: you need to provide the email
16:00:10 <flaper87> the one you used for your trello account
16:00:11 <nikhil_k> TravT_: yeah, we can't risk breaking rest of things on Friday . So, if we get the patches ready today we will go ahead with the release
16:00:25 <jokke_> time
16:00:43 <jokke_> can we continue the client release on #openstack-glance for a min?
16:00:44 <TravT_> nikhil_k: why not? i always release code on a Friday night and then go home for the weekend. ;)
16:00:47 <nikhil_k> zhiyan: you'r added
16:00:56 <nikhil_k> TravT_: heh, perfect!
16:00:56 <zhiyan> nikhil_k: thanks
16:01:10 <nikhil_k> Thanks all!
16:01:14 <nikhil_k> #endmeeting