20:02:40 <markwash> #startmeeting glance
20:02:41 <openstack> Meeting started Thu Oct 31 20:02:40 2013 UTC and is due to finish in 60 minutes.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:45 <openstack> The meeting name has been set to 'glance'
20:02:55 <esheffield> we have little monsters wandering through the office pilfering sweets :-)
20:02:55 <Guest13638> o/
20:03:20 <markwash> hehe
20:03:38 <markwash> special "halloween" episode of the glance meeting
20:03:44 <nikhil___> markwash: did you get a chance to look at eddie's pic
20:03:48 <markwash> and here I haven't gorged myself on candy yet
20:03:53 <nikhil___> markwash: haha yeah :)
20:04:07 <markwash> nikhil___: no I think I must have missed that
20:04:17 <nikhil___> here it comes
20:04:19 <nikhil___> https://drive.google.com/file/d/0B9Ycgkgf21YCcHJDR0c2MDhPZTQ/edit?usp=sharing
20:04:41 <zhiyan> hi
20:05:16 <markwash> agenda here: https://etherpad.openstack.org/p/glance-team-meeting-agenda
20:05:53 <markwash> only real items on there are: 1) glanceclient cross-version api and 2) worker checkin
20:06:04 <markwash> let's talk about glanceclient first
20:06:12 <markwash> #topic glanceclient v1/v2 cross version api
20:06:32 <markwash> background in the following thread
20:06:35 <markwash> #link http://lists.openstack.org/pipermail/openstack-dev/2013-October/016875.html
20:06:37 <esheffield> oh boy
20:06:43 <esheffield> :-)
20:07:31 <markwash> some more background here as well
20:07:33 <markwash> #link https://review.openstack.org/#/c/33327/
20:07:42 <markwash> an old patch we discussed before
20:08:28 <markwash> I think the key question in my mind is, does it really make sense to publish client libs that 100% follow the versioning scheme of the server library?
20:09:15 <esheffield> yeah, I've wrestled with this a bit in my mind as well
20:09:19 <markwash> or should library api versioning be independent?
20:09:46 <esheffield> on the one hand, I like the idea of having the api version differences hidden behind a unified interface
20:10:02 <esheffield> but what do you do with functional differences?
20:10:54 <markwash> yeah
20:11:08 <esheffield> I have not reached a satisfactory conclusion in my thinking :-(
20:11:22 <markwash> I think that might help define the times when you want to make a major version change in the client library as well
20:12:13 <markwash> so in that scheme, we could have done things this way
20:12:26 <markwash> had v1 of the glancelient keep pretty close functionality with the v1 api
20:12:40 <markwash> but it could be portable to the v2 api to a certain extent, if that's feasible?
20:13:18 <markwash> and then when there was v2 functionality that we could not possibly make work with the client v1 interface, we'd have to publish a v2 client as a separate major version of python-glanceclient
20:13:56 <markwash> one thing I'm not sure about is how easy / acceptable it is for us to simultaneously maintain the 1.x "Head" and the 2.x "Head" of the client library
20:14:39 <esheffield> yeah, that could get messy
20:15:15 <markwash> that might be a good question to punt up to the list
20:15:23 <esheffield> tho it might be the "least bad" thing
20:15:34 <markwash> it might be a problem for packagers as well
20:15:59 <esheffield> I would hope that very soon the v1 client could be frozen with no more updates
20:16:40 <esheffield> so might be less of an issue, at least until we hit the flux of a v2 / v3 transition
20:16:47 <markwash> heh
20:17:26 <markwash> how could we freeze it? just not accept more updates to the code in that directory in the client repo?
20:19:03 <esheffield> I guess what I'm thinking is at some point we have a released 1.x client and there are no more updates to that release after some point
20:19:25 <markwash> gotcha, I think that makes sense
20:19:32 <esheffield> less about freezing the code and more of "you want to use glance v1, you have to use glanceclient v1.x"
20:20:23 <markwash> I kinda like the idea of glanceclient v2 being able to work with v1 as well, in some forms. . not sure if such an api is possible
20:21:43 <markwash> esheffield: do you think there are any strategic moves we could take soon to help improve this situation?
20:22:44 <esheffield> possibly something like ghe's patch from earlier
20:22:48 <markwash> and are there any other folks who feel like they have spare bandwidth to work on this v1 v2 compatibility for nova?
20:23:07 <esheffield> an interface that supports the most common functionality between the two at first
20:23:37 <markwash> how close is Ghe's patch to that?
20:23:47 <twoputt> I would be interested to know how to deal with the "location" with the v1 api?
20:24:23 <esheffield> well, ghe's patch was mostly the imageservice pulled from nova
20:24:41 <esheffield> so it was still just v1, but basically represented that common functionality
20:25:04 <esheffield> the patch I have up for nova essentially allows switching v1 / v2 behind that interface
20:25:36 <twoputt> and not have both of them, that's correct?
20:26:37 <nikhil___> what is the location issue?
20:26:47 <nikhil___> sorry, I'm not super familiar with this
20:27:09 <twoputt> my understanding is that you can get the location(s) of the image with the v2 api
20:27:24 <zhiyan> twoputt: glance only show direct url/location to client in v2 api, if admin enable it.
20:27:50 <markwash> hmm, but its definitely something we'd like nova to use
20:28:08 <markwash> on the consumer side its easy, nova can use the location IF its present
20:28:08 <zhiyan> twoputt: yes, v1 always not expose location to client.
20:28:52 <markwash> on the producer side (nova uploading an image directly to a store, and then passing the location off to glance) there might be some compatibility as well
20:29:03 <markwash> so maybe that just works
20:29:04 <twoputt> so for example, in the future the vmware driver in nova will need to get this location. consequently, nova should be able to talk v1/v2 at the same time
20:29:09 <markwash> of course, v1 won't show multiple locations
20:30:00 <zhiyan> v1 won't show any locations
20:30:18 <markwash> zhiyan: right, sorry
20:30:26 <twoputt> ok
20:30:34 <markwash> I meant to say, v1 can accept a *single* location as a register action
20:30:50 <markwash> but does not have semantics for adding a location
20:31:44 <markwash> so if we wanted to nova to do cool stuff like upload to multiple stores on snapshot, for example to save to cinder and swift, the common client could not support that
20:32:41 <esheffield> sounds that way to me
20:33:08 <markwash> well, I'm having a hard time wrapping my head around this now :-(
20:33:59 <markwash> maybe we should revisit the issue later?
20:34:09 <esheffield> heh, welcome to my world of the last couple months! :-)
20:34:52 <nikhil___> say 5 for tasks and we'r game :)
20:35:10 <markwash> #topic tasks
20:35:24 <zhiyan> markwash: so from Ghe's patch, you prefer we move the nova/cinder 's consuming code to glanceclient? but i'm confulsed is that for nova/cinder it still need choice using v1/image_service.py or v2/image_service.py , since they are just different essentially ...
20:35:49 <markwash> whoops, switched too soon!
20:36:00 <zhiyan> markwash: :)
20:36:19 <markwash> zhiyan: I think that's a reasonable confusion
20:36:28 <zhiyan> markwash: i'm ok, we can talk this later.
20:36:39 <esheffield> zhiyan: right now the glance functionality that nova needs is common to v1 and v2, so a single image service could work with swappable "drivers" for v1 / v2 behind it
20:36:40 <markwash> one sec, I think your comment is a bit of clarity for me
20:37:18 <esheffield> but if nova starts to require say multiple locations, that's a v2 only thing so that becomes more problematic
20:37:25 <twoputt> yes
20:37:35 <twoputt> and I think this might come soon
20:38:03 <zhiyan> esheffield: but IMO only some special function, like locations, can help nova do sush cool things...
20:38:05 <markwash> if that's the case, then we just need to figure out how to get everyone useing v2
20:38:48 <zhiyan> markwash: so the migration cost is high, 1->2, 2->3..
20:39:41 <markwash> so, if we could make a client API that makes the helpful parts of v2 discoverable
20:39:49 <zhiyan> seems the cost probably can not be saved.
20:40:09 <markwash> like, say if the library tells you something useful like "can we add locations?"
20:40:32 <markwash> then its possible nova could be using this client API with both v1 and v2 glance
20:40:39 <esheffield> duck typing ftw!
20:41:00 <markwash> and only try to do these new features if the library says they're available
20:41:33 <esheffield> that does mean client users have to be ready with a fallback
20:41:47 <esheffield> if an expected feature isn't there
20:42:05 <markwash> esheffield: yeah, true. . there may be graceful fallbacks though. . I'm not sure
20:42:10 <zhiyan> i'm thinking how it work if glance server disable one api version
20:42:48 <zhiyan> if so, we need have a function list, allow consumer do the function-availibitly query
20:43:19 * markwash falls back into a bit of confusion
20:43:53 <zhiyan> next topic? time is short, and nikhil___ i waiting :)
20:44:05 <markwash> I guess let's keep stewing on this and see if we have any clearer ideas in the future
20:44:11 <markwash> #topic tasks for real
20:44:14 <markwash> tasks!
20:44:30 <nikhil___> yay!
20:44:44 <markwash> what's the latest update?
20:44:46 <nikhil___> thanks all for all the prompt reviews when we needed it most :)
20:44:52 <nikhil___> really really appreciate it!!
20:45:12 <nikhil___> markwash: I updated the latest executor interface patch up
20:45:29 <nikhil___> https://review.openstack.org/#/c/44355/
20:45:48 <nikhil___> and this completes the chain for all that has been discussed and is waiting for reviews
20:46:29 <nikhil___> wanted to ask if we had (at least some level) of agreement of the executor interface supported atm ?
20:47:41 <markwash> nikhil___: is it basically just the "run(task_details)"  that I see?
20:48:28 <nikhil___> markwash: general outline of the factory/pattern proposed atm
20:48:54 <nikhil___> yeah and now I see that it mostly relates to run task part
20:49:21 <zhiyan> nikhil___: not sure you noticed, i have put some comments in https://review.openstack.org/#/c/46117/
20:49:35 <nikhil___> would folks be available to review during the summit ? :)
20:49:40 <zhiyan> i think they are applicable for #44355
20:49:50 <markwash> nikhil___: I see a little difference there in the executor factory
20:49:54 <markwash> the way it is used makes a lot of sense
20:50:08 <markwash> but the way its defined, it looks like you pass in the task itself
20:50:16 * markwash might be wrong
20:50:24 <zhiyan> nikhil___: i think/like do it in my night (really night, this time)
20:51:21 <markwash> I'll definitely be able to review today and during the summit somewhat
20:51:33 <nikhil___> markwash: def run(self, task_id, task_status, task_type, task_input): has this signature proposed
20:51:51 <nikhil___> this would be kind of a contract, I'm guessing
20:52:15 <markwash> okay cool, i'll focus on that in my review in the next few hours
20:52:22 <nikhil___> between the scripts and glance code supporting them
20:52:29 <nikhil___> thanks markwash zhiyan
20:52:40 <markwash> does that cover tasks for now?
20:52:43 <nikhil___> zhiyan: did not quite get your earlier comment though
20:52:56 <zhiyan> np nikhil
20:53:12 <nikhil___> markwash: yeah, mostly. I wanted to see how the position was of community
20:53:15 <nikhil___> on this MP
20:53:16 <markwash> okay cool
20:53:21 <markwash> I think generally positive
20:53:25 <markwash> from me at least
20:53:28 <nikhil___> https://review.openstack.org/#/c/54198/6
20:53:40 <markwash> last few minutes for open discussion?
20:53:43 <nikhil___> that has some comments and will address that
20:54:15 <nikhil___> some discussion was around the status transition checks and wanted to ensure everyone was on the same page about how status is being viewed in general
20:54:29 <zhiyan> nikhil___: thanks
20:54:38 <nikhil___> seems to be like status and state of tasks is kinda intermingled so that's that
20:54:50 <nikhil___> that was the last bit, promise. markwash  :)
20:55:07 <markwash> no worries
20:55:10 <markwash> #topic open discussion
20:56:23 <twoputt> is it the good time to ask for reviews? :) that's my first glance meeting *halloween*
20:56:23 <markwash> as I suspected :-)
20:56:25 <zhiyan> quick asking, can someone tell me what "atm" mean? thanks
20:56:38 <markwash> twoputt: sure, any time is good for review requests!
20:56:50 <markwash> zhiyan: "at the moment" I believe
20:57:14 <zhiyan> aha, got it
20:57:38 <twoputt> I have this small patch https://review.openstack.org/#/c/52998/ -- any feedback would be nice ;)
20:59:36 <markwash> cool
21:00:05 <markwash> all right, thanks folks, happy halloween!
21:00:09 <markwash> #endmeeting