20:00:11 <markwash> #startmeeting glance
20:00:15 <openstack> Meeting started Thu May 30 20:00:11 2013 UTC.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:18 <openstack> The meeting name has been set to 'glance'
20:00:19 <markwash> #topic greetings
20:00:23 <markwash> hi everybody
20:00:27 <iccha> hello markwash
20:00:43 <iccha> nikhil: and ameade should be here soon..
20:01:06 <markwash> cool
20:02:05 <markwash> esheffield: o/
20:02:09 <markwash> anybody else glancy here?
20:02:10 <esheffield> hi
20:02:16 <rosmaita> hello
20:02:39 <markwash> rosmaita: flaper87: o/
20:02:42 <flaper87> o/
20:03:04 <markwash> #topic agenda
20:03:17 <markwash> I've got the standing agenda stuff here
20:03:19 <markwash> #link https://wiki.openstack.org/wiki/Meetings/Glance
20:03:34 <markwash> the main things I gathered for today are blueprints, but I'm not sure that's our most important topic
20:03:44 <markwash> so does anybody else want to suggest something for todays agenda?
20:04:07 <iccha> markwash: is there way to classify blueprints as nice to have vs must haves?
20:04:12 <jbresnah> i would like to get concensus on the API for the multilocations changes i made if possible
20:04:35 <iccha> markwash: i want some direction on protected properties, and push for documentation of flance v2 api
20:04:37 <markwash> iccha: I think so, basically the priority
20:04:37 <ameade> here now!
20:04:47 <rosmaita> i'd like to see what people think about a new 'image-action' resource vs. modifying the image resource
20:05:19 <nikhil> hi
20:05:19 <markwash> cool yay lots of items
20:05:23 <flaper87> I would like to discuss all those topics :D
20:05:27 <nikhil> new meeting time?
20:05:32 <nikhil> or will it be same?
20:05:46 <markwash> nikhil: I forgot to set up an alternate time
20:06:09 <nikhil> ah k, well I just saw it somewhere and brought it up
20:06:10 <rosmaita> markwash: \o (dind't mean to leave you hanging)
20:06:11 <markwash> (-_-)
20:06:34 <nikhil> this time works well with me, not sure about alternate one (would like to be in sync)
20:06:38 <markwash> cool, I think we can hit all of those items
20:06:50 <markwash> I have 2 blueprints I wanna deal with really fast, if that's okay
20:06:59 <nikhil> +1
20:07:01 <flaper87> go
20:07:02 <markwash> #topic blueprints
20:07:14 <markwash> to keep this timeboxed, lets either say definite yes/no or defer the discussion
20:07:37 <markwash> #link https://blueprints.launchpad.net/glance/+spec/automatic-image-update
20:07:37 <nikhil> k
20:07:43 <markwash> take a look
20:07:59 <markwash> basically, the idea is to propagate changes from base images to snapshots based on them
20:08:06 <flaper87> markwash: remember there's a vote functionality we can use
20:08:24 <markwash> the only way I can think for this to work, it would have to know about filesystems and be able to change checksums of existing images
20:08:26 <iccha> does glance need to do this? or its like an additional script will suffice?
20:08:37 <markwash> so I propose we resoundingly reject this bp as a part of glance
20:08:46 <nikhil> think glance would also need some changes
20:08:46 <ameade> no
20:08:47 <rosmaita> +1
20:09:05 <rosmaita> (to reject, i mean)
20:09:16 <flaper87> no
20:09:23 <markwash> no we should not reject it?
20:09:35 <iccha> reject
20:09:40 <flaper87> reject
20:09:43 <markwash> you guys vote funny
20:09:44 <ameade> reject
20:09:49 <jbresnah> markwash: it makes me wonder our plans for things like OVF
20:09:56 <nikhil> ofd
20:10:04 <nikhil> (open for discussion)
20:10:04 <jbresnah> and managing a hierarchy of child images
20:10:06 <jbresnah> etc
20:10:12 <nikhil> jbresnah: yeah, +1
20:10:15 <jbresnah> markwash: how deep is this rejection?
20:10:29 <jbresnah> markwash: what they want seems really far from where glance is
20:10:29 <markwash> medium?
20:10:39 <markwash> I'm not sure.
20:10:41 <jbresnah> markwash: but were those other things in place it might not be
20:10:53 <markwash> okay, well, let's just defer then
20:10:58 <markwash> I'll ask a question on the whiteboard there
20:11:05 <jbresnah> markwash: but i am entirely on board with rejecting this for anything in the near term
20:11:06 <nikhil> sounds good
20:11:10 <markwash> okay cool
20:11:14 <flaper87> mmh, it seems to me that blueprint is different from OVF and other supports
20:11:14 <markwash> #link https://blueprints.launchpad.net/glance/+spec/membership-policy
20:11:34 <jbresnah> flaper87: agreed, i just wonder the trajectory is all
20:11:43 <markwash> #link https://review.openstack.org/#/c/29297/
20:11:58 <markwash> #startvote should we accept membership-policies?
20:11:58 <openstack> Begin voting on: should we accept membership-policies? Valid vote options are Yes, No.
20:11:59 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:12:05 <markwash> #vote yes
20:12:22 <markwash> remember you can change your vote :-)
20:12:24 <iccha> #vote yes
20:12:25 <flaper87> #vote yes
20:12:27 <ameade> #vote yes
20:12:43 <esheffield> #vote Yes
20:12:52 <nikhil> #vote Yes
20:12:53 <markwash> seems pretty straightforward, we can still pick on the review
20:12:58 <ameade> #vote Yes
20:13:02 <jbresnah> #vote yes
20:13:15 <markwash> #endvote
20:13:16 <openstack> Voted on "should we accept membership-policies?" Results are
20:13:24 <markwash> well
20:13:28 <iccha> hehe
20:13:31 <markwash> I don't know what just happened
20:13:31 <flaper87> haha
20:13:33 <markwash> anyway, all good
20:13:41 <markwash> that's all I have for urgent blueprints
20:13:42 <esheffield> results are inconclusive apparently
20:13:46 <markwash> haha
20:14:03 <nikhil> can't find that results in any other channel i've open
20:14:12 <markwash> Let's talk about documentation
20:14:17 <markwash> #topic documentation of v2
20:14:31 <markwash> iccha I saw you had a great etherpad breaking down the differences between v1 and v2
20:14:36 <iccha> https://etherpad.openstack.org/glance_v1_vs_v2 has some initial notes  by esheffield and me
20:14:45 <markwash> yes that!
20:14:56 <iccha> but we could definitely add more granularity if we would like
20:15:11 <jbresnah> i would love to see that in a more formal public space
20:15:24 <jbresnah> esheffield, iccha: that is great
20:15:25 <markwash> are you hoping we can have something like a "how to migrate" or "what's changed" kind of documentation?
20:15:34 <markwash> or just more general v2 documentation?
20:15:38 <iccha> there are some inconsistent and not so useful documentation of glance v2 api out there, would be great to substitute with this. we would like both
20:15:47 <iccha> a place with how to use v2 and whats changed
20:15:55 <ameade> http://docs.openstack.org/api/openstack-image-service/2.0/content/
20:15:58 <iccha> for ppl who are considering migrating
20:15:59 <ameade> and not have this wrong
20:16:02 <flaper87> I think a wiki page makes sense
20:16:07 <markwash> iccha do your or esheffield wanna come back to us with a survey of docs and plans next week?
20:16:18 <markwash> *plans for better docs?
20:16:23 <esheffield> ameade: yeah, we already found errors in that one
20:16:36 <markwash> *survey of existing docs
20:16:47 <iccha> sure, and who would we hand this off to for formal documentation?
20:17:10 <markwash> iccha: I'm sure we can talk to annegentle about that
20:17:14 <jbresnah> can it go in the glance/doc/source tree?
20:17:24 <esheffield> flaper87: yes, a wiki is certainly our goal. the etherpad is kind of a "rough draft" area while we explore and organize
20:17:37 <flaper87> esheffield: makes sense
20:17:39 <markwash> iccha: I'm not sure what the resources breakdown is, like how much glance devs should write, vs technical writers folks
20:18:00 <markwash> we definitely want to do something consistent with openstack users expectations here
20:18:14 <markwash> that might dictate the format of our ultimate documentation somewhat
20:18:16 <iccha> action- esheffield and iccha work on plan for documentation and survery existing documentation and possibly places where it should reside?
20:18:34 <markwash> #action  esheffield and iccha work on plan for documentation and survery existing documentation and possibly places where it should reside
20:18:43 <markwash> cool
20:18:53 <markwash> #topic multilocations api
20:19:17 <jbresnah> i have a review out for that and i discussed it a bit with markwash
20:19:30 <jbresnah> https://review.openstack.org/#/c/30517/
20:20:01 <jbresnah> the main situation is that i added api to copy 1 location in an existing store to another store configured with glance
20:20:16 <jbresnah> so if people could check that out it would help me progress on that BP
20:20:31 <markwash> I'll admit, I was at first thinking of this feature as a "register multiple image locations" api, which wouldn't involve glance doing data copies
20:20:47 <markwash> but I don't feel like I have any definitive understanding of the features we're targeting right now
20:21:06 <flaper87> I don't think I am either
20:21:19 <jbresnah> i was worried about the vetting process of that
20:21:25 <jbresnah> i mean, i like that more
20:21:28 <jbresnah> but it opens up issues
20:21:38 <markwash> jbresnah: agreed! there is basically no vetting which seems dangerous
20:21:41 <jbresnah> there is no way to check that the various locations actually match
20:21:56 <markwash> yeah
20:22:05 <markwash> so maybe our action item is for folks to weigh in on the review?
20:22:05 <jbresnah> this was all i could come to that would mean progress without an entire mind cluster
20:22:13 <jbresnah> that would be great
20:22:29 <markwash> cool, and thanks for driving this jbresnah
20:22:38 <markwash> I'm excited about landing it in h2 which seems very likely at this point
20:22:39 <rosmaita> markwash, jbresnah: what do yo mean by "vetting"?
20:22:50 <jbresnah> markwash: i hope so
20:22:53 <ameade> well dont merge this review till i get to have a good look
20:22:55 <jbresnah> but i am on baby time
20:22:57 <markwash> rosmaita: ensuring the quality of something
20:23:00 <jbresnah> that is why i am pushing it a bit
20:23:07 <rosmaita> of the bp, or of the location?
20:23:23 <markwash> rosmaita: of the image
20:23:24 <jbresnah> rosmaita: well, if you have an image id
20:23:28 <jbresnah> and you want to add another location
20:23:42 <jbresnah> you could just say: ok add this new location: http://google.com
20:23:47 <markwash> lol
20:24:01 <jbresnah> in one sense it is 'buyer beware'
20:24:11 <jbresnah> but it opens a can of worms
20:24:23 <jbresnah> while having glance copy it into its configured stores allow progress
20:24:25 <nikhil> we need whitlisting no?
20:24:36 <jbresnah> and allows us to get to the other blueprint regarding metadata on those locations
20:24:43 <nikhil> thought we'r going to add that on store level SLAs
20:24:50 <markwash> nikhil: ?
20:25:01 <nikhil> markwash: :)
20:25:11 <nikhil> markwash: I was talking about the locations conversation
20:25:31 <nikhil> and white-listing of the location based on catalogue or something
20:25:31 <markwash> okay, well everybody interested, go have a look at the review
20:25:42 <markwash> I will too, and stop being lame which has been my current alternative
20:25:46 <jbresnah> nikhil: i think the nature of copying to configured stores handles the whitelist
20:26:07 <markwash> are you guys okay with following up later?
20:26:08 <jbresnah> nikhil: the image can only be copied to the stores configured in glance
20:26:12 <jbresnah> just as an upload would be
20:26:19 <jbresnah> markwash: yes
20:26:19 <iccha> i see your point jbresnah . if i am a user and i would like the same image record to point to different locations, i dont want to be individually uploading everywhere and then adding location, it would be cool if glance could do that for me. what are ur concerns mark? i owuld love to hear that. maybe u could leave comments on the review?
20:26:30 <nikhil> jbresnah: ah k, well I need to read more into it. read your conversation with rosmaita a bit differently i guess
20:26:55 <jbresnah> nikhil: oh i see
20:26:59 <iccha> markwash: can u add ur concerns to the review? ^^ so reviewers can be cognizant of it
20:27:05 <markwash> iccha definitely
20:27:05 <nikhil> +1
20:27:13 <jbresnah> nikhil: so instead of google.com, say http://whitelisted.location.com
20:27:20 <nikhil> yeah!
20:27:24 <markwash> I just want to say ahead of time, my concerns aren't as strong as my usual ones, I'm just trying to reason carefully about our api change
20:27:25 <nikhil> thanks
20:27:28 <jbresnah> there is still no guarentee that the images match
20:27:35 <jbresnah> nikhil: same problem exists
20:27:40 <nikhil> k
20:27:46 <markwash> I'm really happy about the progress so far, even if we have to change things up some from the current review
20:27:47 <jbresnah> nikhil: know what i mean?
20:27:58 <nikhil> will understand the issue in depth later from you jbresnah
20:27:59 <jbresnah> maybe we should take this on after the meeting
20:28:01 <iccha> its a cool feature, but it may not be the 'right way' using image location, we can dwell on that
20:28:04 <jbresnah> kk
20:28:06 <nikhil> markwash: seems to be getting
20:28:12 <nikhil> umm.. restless?
20:28:27 <markwash> #topic protected properties and the way forward
20:28:32 <markwash> nikhil: :-)
20:28:41 <markwash> I'm feeling a bit silly today
20:28:49 <nikhil> cat trouble?
20:28:51 <nikhil> :)
20:28:52 <markwash> lol
20:28:53 <markwash> no
20:28:54 <markwash> :-)
20:29:08 <markwash> so, iccha I think this was your item, want to kick us off?
20:29:25 <iccha> stuart's latest suggestion was to add core property for billing
20:29:35 <iccha> which i do not think is the right way forward though the easiest
20:29:49 <iccha> it would not provide a long term solution for protected properties
20:30:09 <markwash> I know you were disappointed to find out all the namespace conflict potential in the v2 property layout
20:30:13 <iccha> we seemed to be hittinh cross roads with the flat hierarchy causing namespace collisions
20:30:26 <markwash> or I should say, the "lack of namespace" conflict potential
20:30:55 <nikhil> -1 to add 'em to core properties
20:31:25 <markwash> I'm wondering now, if there is some merit to an approach to adding optional namespaces to image properties
20:31:32 <markwash> but would that just be the same thing as a prefix?
20:31:35 <iccha> i have just started some work on converting properties to domain model, while we figure out our best way forward...
20:32:08 <iccha> markwash: not necessary prefix ,  "system": {
20:32:08 <iccha> "foo": "baz"
20:32:10 <iccha> },
20:32:16 <nikhil> markwash: makes sense, optional is not as painful
20:32:33 <markwash> iccha: yeah, that's what I was thinking. . it could be a tool to help users and deployers avoid conflicts
20:32:42 <markwash> and it could be considered orthogonal to property protections
20:32:50 <rosmaita> so is the problem that if we don't do namespacing, a customer could put metadata on an image and not be able to modify it?
20:33:08 <nikhil> or modify something else
20:33:15 <markwash> rosmaita: perhaps, but it would be normal to not allow users the "create" permission if you don't allow them the "modify" permission
20:33:40 <markwash> rosmaita: though create without modify is a legitimate class of use cases as well, I think
20:34:30 <iccha> how would we implement protection without have a separate user space which we know we should not interfere with?
20:35:06 <markwash> iccha: can deployers just *know* not to put restrictions on properties their users already have been using?
20:35:50 <rosmaita> i think deployers are currently using the generic metadata for this, and already prefixing the fields
20:36:15 <markwash> rosmaita: right, so the properties they would put restrictions on, they already want to restrict
20:36:26 <iccha> i think the latest suggestion by markwash and the license usecase described by stuart and me is a good starting point which works with flat namespace
20:36:26 <rosmaita> exactly
20:36:26 <markwash> and would view user's modifying those properties as a "bug" ?
20:37:56 <rosmaita> but as far as specifiying protections, i think a deployer would like to be able to set all protections at once on all "com_rackspace" prefixed fields
20:38:12 <markwash> rosmaita: good point, basically prefix-based restrictions
20:38:45 <rosmaita> yes, so it's not really a namespace, but sort of is
20:39:08 <iccha> and we prevent users from adding metadata with that prefix rosmaita ?
20:39:13 <markwash> iccha I get the sense that you are very concerned about deployers having the option to make breaking changes in the api by specifying property protections
20:39:56 <markwash> hmm, we've gone on for about 10 minutes now, maybe we should defer a bit?
20:40:01 <iccha> +1
20:40:10 <markwash> iccha, I'd be happy to talk later today or tomorrow some more
20:40:12 <rosmaita> iccha: depends on the use, i can imagine that you could tell users to put stuff in org_openstack_gui to specify an icon or something
20:40:35 <markwash> I'll follow up with you, okay?
20:40:53 <markwash> but I think we should talk soon to unblock things
20:41:24 <markwash> #topic image actions vs image states for things like import
20:41:51 <rosmaita> do you want me to describe what that means?
20:41:54 <markwash> rosmaita had an email out to the list
20:41:58 <markwash> rosmaita: sure, thanks!
20:42:21 <rosmaita> ok, so when you do an import/export/clone of an image there are two choices
20:42:51 <rosmaita> 1. we create an image, you keep polling it to see the status of your operation
20:43:18 <rosmaita> 2. we create an image_action resource of type import/export/clone, and instead you poll that thing to see the status; if success happens, and image is created
20:44:06 <rosmaita> so 2 complicates the API a bit, but i think it gives us more flexibility in returning error messages and statuses to the person polling
20:44:17 <rosmaita> but, that's jsut my opinion
20:44:22 <rosmaita> i'm curious what y'all think
20:44:28 <markwash> and you can track the success of the action
20:44:47 <markwash> which normally gets squashed by the "active" status of the resulting resource in approach #1
20:45:01 <markwash> and track the original arguments to the action request
20:45:09 <ameade> both seem RESTful.. I like #2 for the reasons mentioned
20:45:30 <markwash> also, IMO complicated state machines are hard, but many simple state machines is easier to deal with
20:45:38 <rosmaita> i like that you don't create an image until you're sure you really have one
20:45:57 <ameade> markwash: +1 +1
20:46:52 <markwash> anybody else +1 for either approach
20:46:55 <markwash> ?
20:47:07 <esheffield> +1 for #2
20:47:19 <jbresnah> sorry I need to get more up to speed on the issue to vote :-(
20:47:48 <nikhil> markwash: unable to comprehend which state m/c is more complicated
20:47:57 <nikhil> however, +1 to #2
20:48:36 <markwash> I think this is just a current poll, not necessarily a vote
20:49:00 <iccha> hmm yeah i get the point about two simple state machines vs one complicated one
20:49:05 <markwash> let me go grab the link for the email chain
20:49:38 * ameade is starting to doubt the RESTfulness of #1...too much reading
20:49:42 <markwash> http://lists.openstack.org/pipermail/openstack-dev/2013-May/009385.html
20:49:47 <markwash> and in general in that thread
20:50:06 <markwash> well, read up, I don't think we're really blocked on either #1 or #2, if somebody wants to start coding :-)
20:50:13 <markwash> #topic open discussion
20:50:39 <markwash> I'll just say, there are some other blueprints on the wiki page for this meeting that folks might find interesting to read up on
20:50:56 <markwash> cool ideas, I'd love to see any feedback from anybody here on those blueprint whiteboards
20:51:17 <jbresnah> markwash: i will put that on my TODO for this afternoon
20:51:24 <iccha> i like the cross-service-id, definitely a useful feature . not sure what the priority on it is though
20:51:42 <markwash> iccha: yeah, seems awesome for tracking things down
20:52:04 <markwash> also I'm not really certain how to use priority on blueprints
20:52:16 <markwash> currently I use "critical" for something that another project would depend on
20:52:23 <markwash> and "not" for things I think don't belong in glance
20:52:34 <markwash> everything else is just "whatever feels right"
20:52:51 <rosmaita> that seems about right
20:53:01 <markwash> anybody else got topics for open discussion?
20:53:41 <jbresnah> xfer service has a bunch of code
20:53:43 <jbresnah> and doc
20:53:48 <markwash> oh cool
20:53:49 <jbresnah> for anyone interested in checking it out
20:53:58 <nikhil> any funny videos come out this week?
20:54:03 <jbresnah> https://github.com/buzztroll/staccato
20:54:11 <jbresnah> cleaning up and adding tests today
20:54:16 <nikhil> jbresnah: that too, sorry wanted to follow up on that
20:54:21 <jbresnah> but after that it will probably sit like that for a few weeks
20:54:55 <markwash> baby time!
20:55:13 <markwash> well, don't take that out of context, folks
20:55:17 <nikhil> haha
20:55:23 <jbresnah> heh
20:55:43 <jbresnah> . o O ( is there a blueprint for that? )
20:55:54 <markwash> lol
20:55:55 <iccha> ok i got to rush guys :) see ya in the channel tomorrow..
20:56:01 <markwash> I think we can close it out
20:56:06 <markwash> thanks everybody!
20:56:10 <rosmaita> bye
20:56:11 <jbresnah> thanks, was great!
20:56:13 <jbresnah> wave
20:56:17 <markwash> #endmeeting