14:02:56 <markwash> #startmeeting glance
14:02:56 <openstack> Meeting started Thu Nov 21 14:02:56 2013 UTC and is due to finish in 60 minutes.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:00 <openstack> The meeting name has been set to 'glance'
14:03:16 <markwash> #link https://etherpad.openstack.org/p/glance-team-meeting-agenda
14:03:18 <zhiyan> rosmaita: :)
14:03:48 <markwash> First a couple of announcements
14:03:59 <markwash> #topic icehouse-1
14:04:06 <markwash> icehouse-1 is rapidly approaching
14:04:18 <markwash> I think its due to be cut on December 5th
14:04:22 <markwash> maybe a day earlier
14:04:24 <flaper87> markwash: correct
14:04:26 <flaper87> Dec 5th
14:04:28 <flaper87> AFAIK
14:04:40 <zhiyan> ~2 weeks later
14:04:46 <flaper87> #link https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
14:04:55 <markwash> #link https://launchpad.net/glance/+milestone/icehouse-1
14:05:20 * flaper87 just targeted https://blueprints.launchpad.net/glance/+spec/oslo-messaging for i-1 since the patch is already there
14:05:27 <flaper87> feel free to push it back
14:05:36 <markwash> since I was triaging so close to the deadline, i mostly pushed stuff to icehouse-2
14:05:37 <markwash> but that's just a projection, anything that we think we can land can go ahead
14:05:56 <markwash> flaper87: great! thanks
14:06:18 <markwash> if folks have other bps they want to land soon, go ahead and target them to i-1 so we can focus review efforts possibly
14:06:22 <zhiyan> markwash: before that ,can i ask you help check/approval bp first?
14:06:37 <markwash> yes
14:06:49 <markwash> wanna link them here now so I have a little todo list we can check back on?
14:08:28 <rosmaita> markwash: there are 2 more bugs along the lines of #1251518 that should be targeted for i-1
14:09:08 <markwash> hmm, can I trouble you for the full links? when I click on the #<number> I get a lonely empty freenode room :-)
14:09:26 * rosmaita is looking for them
14:10:24 <rosmaita> https://bugs.launchpad.net/bugs/1251518
14:10:24 <rosmaita> https://bugs.launchpad.net/glance/+bug/1252459
14:10:26 <rosmaita> https://bugs.launchpad.net/glance/+bug/1252337
14:11:36 <markwash> great
14:11:41 <markwash> those look important!
14:11:57 <markwash> I'm inclined to make them I-1 critical
14:11:57 <rosmaita> i do what i can
14:12:08 <flaper87> rosmaita: +1
14:12:10 <rosmaita> i think Alex is already working on them, too
14:12:12 <markwash> just to hold our own feet to the fire
14:12:29 <flaper87> I saw them yday, they are important
14:12:37 <flaper87> markwash: +1 for critical
14:12:44 <markwash> zhiyan: if you can, please link the bps you are thinking about in here before meeting end, or just email them to me
14:12:52 <markwash> otherwise, are there any other i-1 pressing concerns?
14:13:03 <flaper87> I saw ameade is already assigned, I guess he's working on them
14:13:25 <flaper87> we should encourage him to ping core devs directly for review on those bugs
14:13:44 <rosmaita> flaper87: +1
14:13:45 <flaper87> otherwise we'll get to the i-1 cut w/o even having looked at them
14:13:47 <flaper87> :D
14:13:52 <markwash> yeah, especially since the review queue is still a bit long
14:13:59 <flaper87> yeah
14:14:13 <markwash> (segue!)
14:14:42 <markwash> well, almost
14:14:47 <markwash> next topic!
14:14:57 <markwash> #topic glanceclient version 1.0.0
14:15:19 <markwash> I created a new development series in python-glanceclient on launchpad called v1
14:15:38 <markwash> its my intention that bugfixes/bps that are technically breaking changes could be targeted to that
14:15:52 <flaper87> markwash: can you quickly summarize what are the breaking changes introduced in the new release ?
14:15:59 <flaper87> I think I lost track of some of those
14:16:05 <markwash> yeah, there are a few I know of
14:16:12 <markwash> but I want to make sure other folks can suggest and evaluate them
14:16:20 <markwash> 1) drop legacy cli
14:16:28 <markwash> 2) change default page size
14:16:39 <markwash> 3) maybe something with better version handling for endpoints
14:17:11 <markwash> 4) I'd actually like to switch to requests which means at least temporarily losing control over ssl compression
14:17:37 <markwash> 5) in the CLI, don't create an image if no arguments are passed to image-create
14:17:57 <markwash> I've also been trying to figure out how we will stage and manage all these changes
14:18:00 <flaper87> 1) +1 2) Shouldn't we enforce this server side? 3) +1 4) +1 5) BIG +1
14:18:09 <flaper87> re 4) I did some work there
14:18:21 <flaper87> I ended up abandoning the patch because of the ssl thing
14:18:38 <flaper87> Actually
14:18:39 <markwash> flaper87: yeah, I think for #2 we really need  the default on the client to be to send nothing, so the server can pick
14:18:44 <markwash> yeah, I was just looking at that patch
14:18:54 <flaper87> I didn't abandoned it because of that. I workarounded the whole ssl thing
14:19:04 <markwash> bcwaldon was working on rebasing it a while back as well
14:19:04 <flaper87> and kept the compression code Stuard worked on
14:19:15 <flaper87> but it got lost somewhere
14:19:19 <flaper87> cool
14:19:24 <flaper87> I'm +1 for using requests
14:19:30 <markwash> I've been working on finding a place for staging all these changes
14:19:34 <markwash> and sent an email to the list
14:20:12 <markwash> #link http://lists.openstack.org/pipermail/openstack-dev/2013-November/019911.html
14:20:32 <markwash> so that about sums that part up, any other thoughts on the glanceclient?
14:21:19 <markwash> cool
14:21:25 <flaper87> we should consider to take some of the code that currently exists in nova and pull it in
14:21:34 <flaper87> remember that patch that got blocked ?
14:21:37 <markwash> yes
14:21:41 <flaper87> maybe find a better way to do that
14:21:46 <markwash> I strongly agree
14:22:03 <markwash> especially as location stuff gets a little more complicated and better presented
14:22:11 <flaper87> +1
14:22:14 <zhiyan> markwash: +1
14:22:24 <markwash> I think the client would be a great place for us to standardize things like how to select 1 out of the available image locations
14:22:47 <markwash> next up, looking at the review queue
14:22:55 <zhiyan> markwash: so for this do you thinks we can reuse gho's patch? and rething about interface
14:22:56 <zhiyan> ?
14:23:04 <markwash> I'm not sure
14:23:11 * flaper87 neither
14:23:18 <flaper87> I think that patch needs a major rework
14:23:27 <flaper87> although I +2'ed back then
14:23:29 <flaper87> :D
14:23:30 <markwash> after being reminded how much work it is to deprecate and drop API stuff in the clients
14:23:39 <markwash> I'm glad we didn't land that one
14:24:11 <markwash> at least without more evaluation
14:24:22 * markwash was at least nervous
14:24:24 <zhiyan> tbh, i'm not very clear the goal
14:24:34 <markwash> the goal of?
14:24:45 <zhiyan> glance client lib
14:25:09 <zhiyan> i mean the details of the landing path
14:25:30 <markwash> I think we could benefit from actually trying to write down the goal
14:25:44 <markwash> I think there is good stuff there, but its not always clear what we're trying to accomplish, I agree
14:25:54 <markwash> in particular, with the way the api libs are laid out
14:26:53 <markwash> but I think that might be enough for now
14:27:05 <markwash> #topic review backlog
14:27:21 <markwash> we are down to 61 open reviews
14:27:28 <markwash> that's actually a pretty big improvement over last week
14:27:54 <markwash> I think our average response time has also dropped by nearly a week
14:28:10 <markwash> or at least 4 days, something like that
14:28:17 <markwash> great work everybody!
14:28:28 <flaper87> w000t
14:28:40 <zhiyan> markwash: if gate work well, the number will better :)
14:28:50 <markwash> zhiyan: that is true
14:28:52 <flaper87> o/ I think there are some important, historical, patches that need some attention, though.
14:28:56 <flaper87> for example: https://review.openstack.org/#/c/34801/
14:29:23 <flaper87> that was opened on June 27th
14:29:29 <markwash> "Remove user and key from location in Swift"
14:29:36 <markwash> yeah that review is definitely on my mind
14:29:46 <markwash> there has been some recent discussion which I guess has been unfortunately kind of hidden
14:29:54 <markwash> which has kept me from pursuing that
14:30:00 <flaper87> oh
14:30:40 <markwash> rosmaita: would you say the conversations we've been having with smclaren about solving the credentials problem are relevant to that patch?
14:30:47 <markwash> and might change the direction we want to go?
14:31:00 <rosmaita> yes, i would hold off on that patch
14:31:34 <rosmaita> i can post Stuart's doc link if others are interested
14:31:45 <flaper87> rosmaita: yup, please.
14:31:49 <markwash> I might -1 it with a note just to pull it out of the stats
14:31:57 <rosmaita> don't mean to work hidden, but don't want to broadcast our prob
14:32:07 <markwash> right
14:32:11 * rosmaita looking for link
14:32:36 <iccha> hey hey sorry forgot it hifted to 9 am
14:32:54 <rosmaita> https://region-a.geo-1.objects.hpcloudsvc.com:443/v1/61624292678963/public_referenced/logical-swift-store.pdf
14:32:55 <markwash> I did come up with one bookmark link I wanted to share with other reviewers since its helped me out a lot this week
14:33:09 <markwash> https://review.openstack.org/#/q/status:open+project:%255Eopenstack.*glance.*+branch:master+label:CodeReview%253D2+-label:CodeReview%253D-1+-+label:CodeReview%253D-2+-label:Approved%253D1,n,z
14:33:31 <markwash> ^^ will show you all the reviews that really just need one more +2 and an approval
14:33:45 <zhiyan1> markwash: yes, it's true, also for me.
14:34:03 <markwash> its sometimes an area with "easy" reviews, but I think its also useful because it reduces the time a patch can sit around and catch rebase conflicts, assuming you're happy with it
14:34:11 <flaper87> markwash: rosmaita so, is that something 'swift' store specific?
14:34:25 <rosmaita> flaper87: yes and no
14:34:31 <markwash> flaper87: not entirely swift-specific. . there are other stores that have credentials
14:34:59 <flaper87> yeah, sorry, I meant to ask. Is that fix something we can replicate on other stores?
14:35:01 <rosmaita> i think the problem is more general, but we (hp, rackspace) use swift and are most concerned about it
14:35:08 <markwash> but its conceivable that solutions might be store-specific
14:35:16 <rosmaita> too early to say
14:36:03 <flaper87> would it be better to have that on a wiki page ?
14:36:09 <flaper87> StoreCredentialsManagement
14:36:12 <flaper87> or something like that
14:36:20 <ameade> here now >.<
14:36:48 <markwash> I think a general fix for this problem would probably be a great thing to get done ASAP, as a prerequisite to some of the client work with locations we were talking about
14:37:34 <markwash> so anyway, in summary, great work on reviews this past week and lets keep it up! once the queue is small we can relax a bit
14:37:46 <iccha> flaper87: the s3 store
14:38:02 <iccha> flaper87: i was looking for other stores with sridevi and thats the other one we noticed
14:38:10 <markwash> #topic meta
14:38:20 <flaper87> iccha: cool, thanks for the heads up
14:38:34 <markwash> so I was hoping we'd have some time here to brainstorm about ways to fix our sort of disasterous blueprint organization
14:38:53 <markwash> maybe its not so bad, but I personally can't make heads or tails of our blueprints from the general list
14:39:26 <markwash> but that discussion is probably long, and there are two other topics that have been added to the agenda
14:39:38 <markwash> anybody prefer to talk about blueprint organization now? or maybe some other time?
14:40:05 <flaper87> I think maybe other time
14:40:20 <flaper87> since the next 2 topics are still related to blueprints
14:40:25 <iccha> i woud like time to go through the list
14:40:35 <flaper87> and upcoming designs
14:40:38 <flaper87> and what iccha said
14:40:40 <flaper87> :D
14:40:43 <markwash> okay cool
14:40:43 <iccha> sorry about not being better prepared
14:41:01 <markwash> I should probably also jsut take a look at what some other projects are doing with theirs
14:41:31 <markwash> now, in hopefully fastest-first order
14:41:47 <markwash> #topic Doc update
14:42:00 <markwash> rosmaita?
14:42:11 <rosmaita> yo
14:42:11 <iccha> most imp topic :) we really need it!
14:42:30 <markwash> rosmaita: sorry, just trying to give you the floor
14:42:35 <rosmaita> sorry, ok
14:42:56 <rosmaita> so the patch i've got up handles defining the 2.1 version of openstack-json-patch
14:43:10 <rosmaita> but, the missing part is the change to the "restricted json pointers"
14:43:30 <rosmaita> since now you can do multilevel references for hte location field
14:43:37 <markwash> ah yes
14:43:39 <rosmaita> i am a little unclear how we want to go on that
14:43:48 <rosmaita> whether a general multilevel deal
14:44:00 <rosmaita> or only allow /location/whatever
14:44:28 <rosmaita> so i was wondering if someone more in the know would like to write it
14:44:36 <markwash> it will probably take a bit of looking at the code again, as well
14:44:54 <markwash> rosmaita: is there a drop-dead date for this assignment?
14:45:08 <rosmaita> not really
14:45:17 <zhiyan1> rosmaita: after first glance, do you have plan to involve location part in your doc change?  seems there's not
14:45:24 <rosmaita> i can just split the bug and leave the multilevel pointers hanging, and get the new json patch stuff in
14:45:41 <markwash> rosmaita: I'd like to help, I'm just afraid I'll forget or get distracted
14:45:53 <markwash> like if there's something shiny or whatever
14:45:55 <rosmaita> zhiyan1: probably put an update in the GET images/{image_id} call
14:46:10 <rosmaita> and another example for PATCH /images/{image_id}
14:46:39 <rosmaita> well, if no one thinks it's pressing, it may take me a while to get around to it
14:46:58 <rosmaita> like after i get the import/export tasks written up
14:47:04 <markwash> rosmaita: how about split it and assign it to me
14:47:12 <markwash> and then if you remember to, bug me about it :-)
14:47:15 <rosmaita> markwash: +1
14:47:37 <markwash> moving on. . .
14:47:47 <markwash> #topic Glance Image Handlers (zhiyan)
14:47:56 <flaper87> that was me
14:47:57 <flaper87> :D
14:48:00 <markwash> oh
14:48:02 <markwash> haha sorry!
14:48:06 <flaper87> no worries
14:48:08 <flaper87> :P
14:48:10 <markwash> #topic Glance Image Handlers (flaper87 )
14:48:11 <zhiyan1> rosmaita: i prefer add a location PATCH example for end user
14:48:30 <flaper87> so, we had this conversation during the summit about being able to group images and supporting image templates
14:48:41 <rosmaita> zhiyan1: +1, will note in bug
14:48:42 <zhiyan1> also thinking are we talking the same point? flaper87
14:48:46 <flaper87> I wanted to get other folks feedback on that topic and perhaps start working on a blueprint for that
14:48:55 <zhiyan1> rosmaita: thanks.
14:49:26 <flaper87> The idea is to have a separate resource that knows about iamge tempaltes
14:49:37 <flaper87> as images know about images' formats
14:49:38 <zhiyan1> flaper87: actually i did some work around that, flaper87 https://review.openstack.org/#/c/33409/
14:49:59 <markwash> zhiyan1: I think actually maybe that is different
14:50:04 <markwash> but we're just using the same word "Handler"
14:50:10 <flaper87> indeed
14:50:26 <zhiyan1> oh? looking
14:50:45 <flaper87> so, this images' tempaltes will also make what zhiyan1 did easier to implement
14:50:53 <iccha> i think some folks brought this up at the portland summit as well
14:50:56 <markwash> so, an image template would be something like, this image for /dev/sda, this image for /dev/sdb? or something else?
14:51:37 <iccha> is there a specfic format? what would template look like?
14:51:59 <flaper87> Those templates are very hipervisor specific
14:52:32 <markwash> oh, like vmware templates as images?
14:52:36 <flaper87> markwash: yup
14:52:58 <iccha> i think there exists a bp for it? lemme dig
14:53:05 <flaper87> oh, is there?
14:53:07 <flaper87> mmmh
14:53:20 <markwash> you also mentioned grouping images
14:53:24 <flaper87> so, I was thinking about not just creating a resource that people can upload templates too
14:53:29 <iccha> flaper87: https://blueprints.launchpad.net/glance/+spec/hypervisor-templates-as-glance-images
14:53:41 <flaper87> but make it smart enough to link existing glance images to that template
14:54:11 <iccha> https://blueprints.launchpad.net/glance/+spec/rhev-m-ovirt-templates-as-glance-images
14:54:12 <flaper87> so that when users download that template, it already holds the information of the images that belong to it
14:54:14 <flaper87> etc
14:54:32 <iccha> flaper87: so maybe somehing which over arcs/ generalizes all these bps?
14:54:32 <zhiyan1> flaper87: just like ova?
14:54:35 <flaper87> iccha: awesome, thanks a lot!
14:55:15 <flaper87> so, as for now, Glance just knows about images
14:55:17 <markwash> flaper87: ah okay. . so this proposal is like representing *some* of the complexity of ovf in glance
14:55:37 <zhiyan1> sounds like ova to me still
14:55:51 <flaper87> markwash: yes, but keeping it hypervisor / tempalte agnostic
14:55:58 <markwash> yeah
14:56:10 <flaper87> zhiyan1: yeah, kindof
14:56:14 <markwash> which man, I wish ova/ovf were hypervisor agnostic, but it seems probably not
14:56:27 <flaper87> markwash: indeed
14:56:38 <markwash> I think we're clearly building some mental momentum around this kind of idea
14:56:42 <flaper87> and I don't think we want to pull the hypervisor knowledge into glance
14:57:09 <markwash> I think for it to get real traction I wanna figure out how we can make sure we have nova buy-in
14:57:20 <flaper87> yeah, I haven't worked on a *real* proposal yet because I wanted to get folks thoughts about this
14:57:40 <markwash> I mean, for the "disks arrangement" part of ova, I'm pretty sure Nova will be mostly happy
14:57:41 <flaper87> markwash: it'll require some work in the nova side
14:58:15 <markwash> even an initial proposal could be really useful for fleshing things out
14:58:24 <zhiyan1> flaper87: under my plan, we can just allow user to put ova into glance as a common image file, and do that magic thing on nova/consumer side, under my image handler approach
14:58:40 <zhiyan1> flaper87: so i'm interested in what you want to do on glance side
14:58:42 <markwash> zhiyan1: I think we might have to do that in the short term, but libvirt is never gonna support ova
14:59:14 <flaper87> and I don't like 'tempaltes' being treated as images
14:59:21 <zhiyan1> markwash: yes, but vmware folks can implement a particular ova handler for esxi/vc hypervisor
14:59:29 <flaper87> I think is wrong and we can do better by having a real resource for it
14:59:31 <markwash> so it would be great if we could sort of make a simpler, more generic, implicitly remote concept of ova and represent it in glance
14:59:39 <markwash> yeah, ova's are not images honestly
14:59:41 <zhiyan1> markwash: that's no limitation, it's a particular handler implementation
14:59:43 <markwash> not in the true sense of an image
15:00:29 <markwash> zhiyan1: the problem is that "particular handler implementations" is a fairly divisive approach to doing stuff, and means that different hypervisors feel very differently and can't interoperate
15:00:34 <ameade> before the meeting is over
15:00:37 <ameade> WRT the new quotas stuff, do we care about backward compat or would sane defaults be better so deployers don't have to worry about it?
15:00:40 <ameade> https://review.openstack.org/#/c/56981/
15:00:50 <markwash> ooh, great question!
15:01:14 <markwash> I think if the default is really bit its probably fine
15:01:18 <markwash> looks like we gotta run!
15:01:29 <flaper87> so, that's it from me. I see some interest and I'll write something about this topic
15:01:31 <markwash> s/bit/big/
15:01:35 <markwash> #endmeeting