20:02:03 #startmeeting glance 20:02:04 Meeting started Thu Jul 25 20:02:03 2013 UTC. The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:06 hi everybody 20:02:07 The meeting name has been set to 'glance' 20:02:15 hi mark 20:02:16 * jbresnah waves 20:02:16 hey 20:02:29 \o/ 20:02:35 my apologies if I have seemed or do seem distracted this week 20:02:52 I caught a bug earlier on, and treatment has kept me a bit spaced-out 20:03:29 Did you file the bug on launchpad? 20:03:43 I would be happy to triage it 20:03:44 the broad topic i want us to address during the meeting today is what we expect/plan to accomplish in H-3 20:03:47 lol 20:03:58 but due to being out sick, I haven't developed a specific agenda 20:04:32 so lets do a quick once-around-the-room to get agenda items from everyone, to make sure we stick to a sensible structure 20:04:36 For h3 i would like to get a patch for storage quota 20:04:44 ify, we discussed in last meeting: https://etherpad.openstack.org/glance-havana3-blueprints 20:04:44 but that is all i have in mind right now 20:06:14 new upload-download workflow recast as "tasks" api 20:06:40 property protections 20:06:44 as an additional item, i think it makes sense to take another look at https://launchpad.net/glance/+milestone/havana-3 20:07:25 I wanna talk a little bit about focusing on bug triage and fixes during H-3, so I'll add that to my list as well 20:08:11 okay, I've got 4 items, storage quotas, property protections, task api, and bug triage 20:08:13 anything else? 20:08:51 not from me 20:09:06 well, and "other h-3 blueprints" if we have time 20:09:15 okay, rosmaita wanna kick things off with tasks api? 20:09:17 i have 3, we discussed yesterday 20:09:23 sure 20:09:25 #topic task api 20:09:36 https://wiki.openstack.org/wiki/Glance-tasks-api 20:09:39 * markwash hands over the mic 20:10:05 the idea is that we can unify import/export/clone in a new uri path 20:10:19 for these operations, we will return a "task" resource 20:10:29 that you can poll to see what's up 20:10:41 eventually you either get success or failure status 20:10:52 and the think has an expiration date, so it can be deleted 20:11:07 that doc above gives the basic outline 20:11:21 it's got links to proposed use for import, export, and clone 20:11:32 there was some discussion on the mailing list 20:11:53 some people would prefer using the image response for this 20:12:13 but i think that's a bad idea, these operations may result in a non-image 20:12:16 i missed that discussion on the ML 20:12:19 so why clog up the db 20:12:31 there's a ref on the above doc if you want to review 20:12:31 what is an example non-image? 20:12:34 was a few months back 20:12:42 jbresnah: an image import that fails 20:12:51 fair 20:12:59 rosmaita: I agree 100% 20:13:00 yeah, i like it to not be an image 20:13:14 I don't want to always use my PTL hat, but I'm putting it on to say no to more complex internal image state 20:13:16 i think the current glance people are ok with this 20:13:21 why is it v2? 20:13:26 as in /v2/tasks 20:13:51 caz v1 prolly should not support that 20:14:02 well, we (as in rackspace) are thinking of only going public with v2 20:14:03 the task portion seems like a new API all together ot me 20:14:26 currently v1 v2 ar efor image handing, and now there is new API for tasks 20:14:31 rosmaita: thanks for the overview, this looks good to me, is there a best place for folks to provide more feedback? 20:14:35 but very minor point 20:14:37 just caught my eye 20:14:47 API-wise i think that is great 20:14:59 i would like to hear about some impl details and architecture 20:15:05 don't have a feedback point, what would be best to use? 20:15:26 don't think there's much impl details yet, been working on the api mostly 20:15:37 there are implied details in the individual docs, though 20:15:39 I don't really want to trigger another internal vs external state discussion honestly, but I guess the ML is still best 20:15:51 ok, i will post after the mtg 20:15:58 and hope for the best 20:16:18 rosmaita: one thing I want to make sure you know, is that there are some other folks outside of your org interested in working on this 20:16:31 that is good news 20:16:35 in particular I know flwang is interested in some of the implementation details, and he and I have had some discussions 20:16:56 rosmaita: how much of this are you imagining will be done for H-3 at this point? 20:17:09 markwash: rosmaita yeah flwang and I had a chat 20:17:17 nikhil: oh good :-) 20:17:23 markwash: he seemes to be of the opinion that everone is on design phase 20:17:32 i would like to work on it as well (i have some reasons to want this as well) 20:17:39 not sure how far along are you both on that one 20:17:40 i think a preliminary implementation, e.g., import with just 1 file format conversion 20:17:41 tho i am not sure i will be able to in the h3 time 20:17:48 same for export 20:17:48 jbresnah: i mentioned it to him that you might be interested too 20:17:53 not sure about cloning, TBH 20:18:00 with rosmaita's recent work, i think we're at a great state in terms of the API design 20:18:16 * rosmaita blushes 20:18:18 there are some details to be worked out internally, but I think we can iterate on that pretty safely 20:18:27 jbresnah: just based on our old discussion 20:18:39 nod 20:18:47 rosmaita: okay, so up to "import" with a simple conversion step for H-3? 20:19:00 i am very interested in what it would take to add a new backend task 20:19:02 markwash: would like to sync up with you on cloning bp after the meeting 20:19:09 if you'r free for a few mins? 20:19:15 markwash: i think so 20:19:33 nikhil: not sure yet, but sometime soon for sure 20:19:35 definitely import, possibly export too 20:19:35 jbresnah: +1 20:19:45 okay, jbresnah wanna move on to talking about storage quotas? 20:19:46 markwash: will send an email 20:19:51 sure 20:19:56 #topic storage quotas 20:20:11 I am working through a patch to do something very simple 20:20:33 just enforce a maximum allowed storage usage across all storage systems 20:20:51 for now the quota would be set as a single value in conf and apply to all users 20:21:23 the idea being that when keystone has more sophisticated ways of setting user based quota information taht the value will come from a keystone query 20:21:36 but the enforcement code will all be the same 20:21:44 sounds pretty straightforward 20:21:58 I was a bit meh on quotas earlier in the cycle, but this sounds reasonable to me 20:21:59 yeah not much to it 20:22:09 oh, and i was thinking of only putting it into v2 as well 20:22:16 at leastfor the first patch 20:22:24 to keep it small and easier to review 20:22:28 how does that sound? 20:22:36 jbresnah: sounds like something that could be easily done in H-3, do you just wanna take feedback on the patch? or do folks need a way to talk this out more before you finish the impl? 20:22:55 yeah h3 20:23:00 i am good with just getting feedback on the patch 20:23:07 unless people are fully against the idea 20:23:16 in which case i would like to know sooner 20:23:23 anybody worried about just giving feedback on the patch? I assume the default setting is "no limit" so it shouldn't be too binding 20:23:32 right 20:24:04 i just think how it work in multiple-location context 20:24:24 each location counts against the quota 20:24:37 you mean 'each store'? 20:24:50 that is an interesting question 20:25:01 right 20:25:09 it is about total usage 20:25:18 if I use my own swift account, and add a location from it, does that count against my shared storage quota? 20:25:31 i could imagine a later patch putting quota on a per-storage system basis 20:25:44 markwash: for this yes 20:26:00 okiedokie, let's keep thinking about it but I think we can still just look at the patch 20:26:21 can I move on to bug triage? 20:26:24 i'd like check details from patch for that. 20:26:26 nod 20:26:29 pls 20:26:33 #topic bug triage in H-3 20:26:59 since we pretty much can't merge anymore after H-3, I think it makes sense to make a few passes through the bug list to try to fix anything critical 20:27:17 so all I'm really asking is for core folks to devote a little extra time to bug management during the next months 20:27:41 after we do some triage, it might make sense to have an actual "bug squash" day, but let's hold off 20:27:50 yeah that sounds like a reasonable request 20:28:18 markwash: oh hey just thought about the mox thread on the ML, should we talk about that? 20:28:47 ameade, added to list 20:28:51 okay, I think that's all from me 20:29:01 rosmaita, wanna move on to prop protections? 20:29:30 ok, so here's something to look at: https://wiki.openstack.org/wiki/Glance-property-protections-product 20:29:35 #topic property protections 20:30:00 so the above is a "product" approach, it's kind of self-explanatory, would appreciate feedback 20:30:22 anyway, i think we're ready here to start work on this tomorrow 20:30:38 okay, cool, so H-3 feels good? 20:30:45 definitely 20:31:01 one note on the FAQ, you suggest that communication about the protections would be out-of-band 20:31:09 but could we also use the schema to communicate those restrictions? 20:31:25 maybe some restrictions are supposed to be 'secret' though. . . 20:31:34 that's what i was thinking 20:31:41 the nonreadable properties 20:31:46 rosmaita: recently we added a notion of "meta data" on storage system locations 20:32:07 i would be great if these protection mechanisms could apply there as well 20:32:37 ok, will have to look 20:32:47 not sure about h-3 for that though 20:32:50 hmm, jbresnah would you buy that as a second pass? it sounds like it might be hard to do at first 20:33:07 yeah, also i can make that my problem 20:33:17 once we get it right for image properties, might not be hard to port to location 20:33:26 jbp - jbresnah's problems 20:33:34 just keep me abreast of whats up 20:33:38 heh 20:33:39 ok 20:33:51 99 jbps but protection aint one? 20:34:09 ...i probably should have gone with properties there 20:34:11 rosmaita: have you heard any more from smclaren about property protections, do you think most folks are on board? 20:34:16 haha 20:34:31 jbresnah: careful, we'll quote that in a court in sweden and then you'll have to learn a lot about extradition law 20:34:45 markwash: have not heard more, will contact him to ask 20:35:01 not sure if he saw your comments on the etherpad 20:35:15 heh 20:35:26 should i send out a mailing list item on property protections? 20:35:36 sounds good, some sort of stub for more feedback 20:35:42 ok, will do 20:35:56 all right, one more from me 20:36:02 #topic other havana-3 blueprints 20:36:10 #link https://launchpad.net/glance/+milestone/havana-3 20:36:24 we need to take a very realistic view of these to try to keep our promises this time around 20:36:57 if you're assigned there, and think there's any chance your bp won't make it for H-3, talk to me and see what we can do to either pare down scope, or push off to I 20:37:07 2 - 3 seem to be all about the task work, is that right? 20:37:24 some of those we already covered a bit in this meeting, so I"ll be updating based on my notes later today 20:38:30 I should also add I'm still very happy about what we delivered in H-2 20:38:32 markwash: do you think we can talk about 'global state machine to maintain image status'? or discussing that later when i start do that? 20:38:48 zhiyan: looks like we should have time 20:38:53 #topic mox thread 20:38:56 ameade, take the lead 20:39:05 #link http://lists.openstack.org/pipermail/openstack-dev/2013-July/012474.html 20:39:06 also can I get a link on that? I'm not up to speed 20:39:08 yes! 20:39:10 read my mind! 20:39:21 basically mox isn't python3 compatible 20:39:39 I think we shoudl do both things chuck suggests there 20:39:56 #2 is the quick solution and we can also slowly phase out mox 20:40:01 I would like to see if we can slowly move towards mock 20:40:13 mostly because I tend to like the tests it results in a bit better 20:40:14 +1 20:40:26 russell sent an email about this 20:40:29 #link http://lists.openstack.org/pipermail/openstack-dev/2013-July/012484.html 20:40:29 ameade: just reading that email i would say pymox sounds perfect 20:40:36 but i wonder what the rest of the debate is 20:40:41 so maybe we port to pymox, and set up a policy that says "no more mox" ? and try to enforce that in review? 20:41:06 +1, the first part of that is the important part, just want to make sure everyone is aware 20:41:07 apparently I'm walking the same path russellb has paved 20:41:34 markwash: are you saying existing mox -> pymox but new tests should use mock? 20:41:38 in glance there are only a handful of mox tests 20:41:41 so this should not be so hard 20:41:53 esheffield: something like that, if folks don't hate the idea too much :-) 20:42:12 markwash: i would go further and say pick the right one and port the tests 20:42:19 just because glance does not have that many mox tests 20:42:31 jbresnah: +1 if that's easy enough 20:42:44 I can't say I can do all the porting required, but if someone can I'd be eager to review and approve 20:42:47 markwash: did i just dig myself a hole? 20:42:50 :-) 20:43:07 i can be involved 20:43:16 do some porting 20:43:18 and reviewing 20:43:20 jbresnah: let's just say someone can opt-in to porting all the tests :-) 20:43:52 #topic global state management 20:44:04 zhiyan can you help me understand what kind of changes you mean here? I'm still a little lost 20:44:44 dibs! i'll port glanceclient to mock 20:45:00 we just have concern about consistent image status management in multiple-locations patchs. 20:45:48 zhiyan: that seems like a big change to me 20:46:00 so for that maybe we need extract those code from controller layer to a dedicated/common place 20:46:01 zhiyan: i honestly dont see it happening to glance at this stage in its life 20:46:07 jbresnah: yes, probable 20:46:28 zhiyan: I think I can see what you're saying then, I'd actually like to see the domain model restructured a bit to move all status updates into glance/domain/__init__.py 20:46:32 maybe, but it would be neccessarily disruptive. 20:46:33 there are some challenges presently to doing that 20:46:53 this is honestly the kind of refactoring that I'd really like to see happen in between H-3 and the I summit 20:47:02 dont take my negativitly wrong tho, i would love to see it happen 20:47:35 markwash: yeah probbly best to have ti at the beginning of a cycle then the end 20:48:00 but at the same time, i am reminded of netscape re-writing its code base 20:48:03 markwash: ok, i think so. i can think about it to get a draft idea later, and discuss with team, then to start it. 20:48:11 and the advice i once got that 'all software sucks' 20:48:11 zhiyan: that might also free up more time for you to focus on some of your other bps, and in other projects where there might be some headwinds 20:48:30 i fear such a change could be more disruptive than helpful 20:48:38 jbresnah: I think its less code than you're thinking 20:48:49 markwash: ok cool 20:48:51 but not sure I have the same picture in my mind as others 20:48:55 markwash: if so then i am all about it 20:49:07 okay, I think we've got a good bit for open discussion 20:49:11 #topic open discussion 20:49:16 * markwash hopes he didn't miss anything! 20:49:26 markwash: do we have plan in h3 to update glanceclient to get fully v2 api support? 20:49:36 oh man that is a good topic 20:49:39 if people have a chance please checkout this patch: https://review.openstack.org/#/c/38606/ 20:49:51 flavio fixed a bug that was hurting me 20:49:59 it is pretty straight forward 20:50:01 zhiyan: we really need that, and I think esheffield has some existing work on it 20:50:09 esheffield: does that sound correct? 20:50:15 zhiyan: +1 20:50:18 i would like to have that too 20:50:47 yes, I have a couple of patches out, and the Thoughtworks team we're working with have done some work as well 20:51:07 great, esheffield please feel free to keep contacting me directly to keep me on task for the reviews 20:51:15 esheffield: markwash: thanks for the update. yesterday cinder folks ask me again. 20:51:25 Sure thing 20:51:50 The changes I have out are for create https://review.openstack.org/#/c/35504/ 20:51:54 and upload https://review.openstack.org/#/c/38359/ 20:52:49 fantastic 20:53:18 well, sounds like we might have dried up on open discussion topics 20:53:22 an other one from me is that: do you think it will be better if we move some properties from image level to image location's level? such as 'is_public' is good for a particular location since currently we have multiple locations for an image? 20:53:22 the cli side will take a bit more work, but I think the library side of this is pretty close 20:53:29 nm 20:53:49 zhiyan: on the surface that makes sense 20:53:53 zhiyan: in general, yes we need to move some things down to the location 20:54:01 I wonder if status could actually move there too 20:54:06 or some portion of it 20:54:14 nod 20:54:21 like pending delete, or saving 20:54:39 we be we can think about it also, and discussing on this summit too 20:54:50 gotta be careful with backward compat in wire protocol 20:55:10 is it time for us to rewrite glance as a protobuf rpc service in go? 20:55:19 heh 20:55:38 yes long overdue 20:55:40 markwash: do you think so? 20:55:59 zhiyan: :-) only a little 20:56:55 sorry, i think it's worth thing, or say under multiple-location situation, some properties should belong with location but image... 20:57:31 zhiyan: oh sorry thought you were asking about my protocol buffers and go comment 20:57:32 :-) 20:57:41 zhiyan: i agree with you 20:57:43 zhiyan: definitey +1 for moving the appropriate properties down to locations 20:57:47 that should probably be a new bp 20:57:49 I think that's going to be a big improvement 20:57:54 and put through those paces 20:58:03 it might be hard to do with the proper backwards compat, but I think it can be done to some degree 20:58:05 markwash: do you think it should happen in h3? 20:58:21 zhiyan: I'm not worried about that right away 20:58:34 I'd love to see a strong definition of what's needed, so we can hammer away at it during the summit 20:58:44 +1 20:58:47 so, i think we can discussing it in summit...and make it in I? 20:58:56 sounds good to me 20:58:58 . o O ( Tho I wont be at the summit ) 20:58:59 great! 20:59:39 jbresnah: don't worry, i will think about how to involve you in 20:59:54 if the internet works :) 20:59:56 and hope you can get there. :) 20:59:56 jbresnah: can't you just take a boat? 21:00:17 markwash: you would think i could, i am not all that far 21:00:50 okay, i got another meeting, thanks everybody! 21:00:54 #endmeeting