20:04:23 #startmeeting glance 20:04:24 Meeting started Thu Jun 27 20:04:23 2013 UTC. The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:04:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:04:27 The meeting name has been set to 'glance' 20:04:32 o/ 20:04:34 \o/ 20:04:36 o/ 20:04:45 \o 20:04:52 /o/ 20:04:53 \ \ 20:04:57 :D 20:04:59 \o/ 20:05:09 \o 20:05:27 glance wave complete 20:05:40 #topic open discussion 20:05:41 :-) 20:05:59 haha nice 20:06:07 Base on our discussion yesterday (my tz), I know markwash and jbresnah consider it's too much implicit automation about the "store location proxy" change did (in https://review.openstack.org/#/c/34501/1 ), so if you/folks have alternative idea around it, please feel free to add comments to gerrit there. thanks. I'd like get your thoughs about it first and discussion with you, then to get a consistent disign. 20:06:20 at some point I would like to revist the quota issue 20:06:41 zhiyan: absolutely, that is high on my list, it might be the weekend before I can try to offer up a sensible alternative 20:06:59 markwash: great! thanks :) 20:07:00 zhiyan: it may be easier to judge that patch when it is hooked into code that is adding and removing locations from the API 20:07:05 zhiyan: and I'm thrilled to have what you have now, it will work, its only a question of if we want to make a little change 20:07:20 zhiyan: as it is now i think it is very clever but i am concerned that it would be too implicit when used 20:07:36 zhiyan: if i saw it in use it would be an easier call to make 20:07:41 yes, yes 20:08:00 zhiyan: did you find the etherpad with how patch ought to work for locations to make sense? 20:08:10 * flaper87 will catch up with reviews tomorrow 20:08:34 marwash: yes, i will take the details in this morning. after reveiw jbresnah new change on multiple-locations-metadata :) 20:08:58 jbresnah: yes, so please add your comments to my change in review. 20:08:59 speaking of reviews, i am on vacation again all next week and it would be great to get comments on this patch before then: https://review.openstack.org/#/c/34492/ 20:09:19 jbresnah: you live on vacation 20:09:21 jbresnah: I promisse I'll take a look at it 20:09:28 jbresnah: sure, take a good reset 20:09:29 zhiyan: will do 20:09:37 jbresnah: cool, thanks, just bumped it up the priority list 20:09:49 flaper87: how's registry db driver stuff going? 20:09:53 markwash: thanks 20:10:13 markwash: so, it's doing well. I already submitted a patch for the json stuff and saw your +2 20:10:24 markwash: wrt the untested call, that is tested in the wsgi tests 20:10:39 that's why I didn't think it was worth it to run that again 20:10:43 does that make sense? 20:10:51 flaper87: sure, cool 20:11:02 I've been running tox -- --with-cover lately and loving it for reviewing tests 20:11:25 markwash: besides that, base db tests run perfectly 20:11:29 oh wait, just a thing 20:11:38 let me get a link for y'all 20:11:40 flaper87: so you just need more reviews? 20:11:48 markwash: that dovetails into another topic i have: unit test coverage 20:12:04 +1 20:12:07 markwash: can we make it policy that any change must have code coverage in unit tests? 20:12:08 markwash: I need another one for that json stuff and then I'll push the big one with the db driver implemented 20:12:14 jbresnah: ++, maybe we should break away from #open for a sec to talk about tests 20:12:19 it would be amazing if gerrit would do that for us... 20:12:38 jbresnah: I think we could request a no-voting gate for that 20:12:51 I would love that as well, I've been giving it some thought 20:12:57 jbresnah: just drop an email in the -dev list 20:13:02 flaper87: maybe that would be too harsh... 20:13:16 I want to detect the *new* tests in a change, and the *new* code, and have a specific report that compares the new coverage with the new code 20:13:19 perhaps just a apolicy of 'no coverage in unit tests is grounds for rejection?' 20:13:28 i can imagine cases where it would be ok 20:13:46 markwash: yeah that would be amazing 20:13:50 its definitely grounds for rejection, I think that's already true 20:13:56 I guess at times we make exceptions 20:14:03 yeah we just need to make sure reviewers aren't accepting something just because it has functional tests but still no unit tests 20:14:04 markwash: even if it is in a functional test? 20:14:05 https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/api.py#L827 20:14:18 I've got an issue with this call (and related ones) 20:14:29 ameade: right i did that today actually, but in my defense i am about to submit a unit test for the change in question 20:14:45 thing is that it receives a property_ref wich is a property instance 20:15:09 that property instance is serialized in the registry driver and sent to the registry service 20:15:13 jbresnah: i'm not calling you out :P 20:15:25 I don't think we need to be extremely aggressive about requiring tests, but I think we should be evaluating coverage as part of review, and make sure that if anything doesn't have coverage, we think its *okay* 20:15:41 +1 that 20:15:48 The registry service doesn't know how to de-serialize it and fails misserably. 20:15:56 and as we switch more and more towards the approach in https://etherpad.openstack.org/glance-improving-test-cycle-times I hope we can find easy ways to require coverage almost all the time 20:15:57 yeah it's all a judgement call (otherwise we should automate it) 20:16:22 +1 20:17:01 flaper87: yeah that looks like it might just be a bug. . does it make sense as a bug? 20:17:21 I could write a deserializer for models but that's not right since other calls just receive an id 20:17:30 markwash: it does make sense 20:17:45 markwash: I wanted to get everybody's aggrement on changing that 20:17:59 messing with the db driver is not fun, nor secure 20:18:36 I don't think public functions in db api should depend on passed values being driver-specific entities (like sqlalchemy models) 20:18:49 markwash: +1 20:18:52 sometimes that hurts performance, and we have to figure out a (usually kind of awkward) workaround 20:19:03 agreed, then, I'll change that 20:19:30 jbresnah: I don't think that's to harsh. Coverage should be enforced in every project, IMHO 20:20:03 and coverage doesn't mean it is well tested, it just means it is all tested. 20:20:13 anybody had a chance to take a look at https://review.openstack.org/#/c/30512/ ? 20:20:15 don't get me wrong, I like the code to be covered 20:20:41 yes, i saw it markwas 20:20:46 * markwash is really excited about moving away from forking functional tests, because those make coverage metrics very hard to generate 20:21:00 markwash: and make debugging much harder 20:21:23 markwash: i will give that another review today 20:21:28 will put in on my list to checkout markwash , have not seen the latest patch 20:21:31 * markwash might resort to selling indulgences to get his patchs +2'd :-) 20:21:36 heh 20:21:43 quid pro quo? 20:22:00 ;-) 20:22:08 if i +2 all of your patches can we avoid that 4am glance meeting? 20:22:13 haha 20:22:23 flper87: and i have a question that seems i have no way to run a single test case from glance... 20:22:40 ? 20:22:56 flaper87: sorry, just you:) 20:23:06 hmm, I've had luck with that, using tox -e py27 -- --tests glance/tests/unit/path/to/test/file.py:TestClass.test_method 20:23:24 that works for me as well 20:23:48 markwash: cool, i will use that in next test runing for dev 20:24:18 I am a bit disorganized today (and maybe always) 20:24:26 does anyone have status updates they want to share for ongoing blueprints? 20:24:38 beyond what we've talked about already. . . 20:24:53 yes, folks, markwash and jbresnah, the BP about image multiple loations support on nova side (https://blueprints.launchpad.net/nova/+spec/image-multiple-location) had approved by Russell Bryant, and the change (https://review.openstack.org/#/c/33409 ) is beta available for you review. (thanks markwash given some valuable comments there and I have responsed :) ), so if you have time please give a review. I just want to parallel glance and nova 20:25:06 with the review i mentioned i get pretty close to multiple-locations being complete 20:25:23 here's a new try for protected props: https://wiki.openstack.org/wiki/Glance-property-protections 20:25:35 don't think stuart has had time to look at it yet, though 20:25:50 jbresnah: are you okay with us taking over a bit in your absence, if we're not quite ready to merge before your vacation? 20:26:02 and iccha: i have updated https://etherpad.openstack.org/remove-sensitive-location-info-glance 20:26:30 markwash: yeah 20:26:37 markwash: definitely on the API side 20:26:47 jbresnah: cool, thanks! 20:27:04 markwash: i have a bit more interest in the metadata parts 20:27:34 jbresnah: nod. . makes sense 20:27:54 rosmaita: looks good to me 20:27:59 but i think my current patch is pretty close 20:28:14 jbresnah: it sounded like it was. . I just haven't had the time to look yet 20:28:28 zhiyan: thanks for your comments, i would rather subtiture user and password with dummy values like 'hidden_user' and 'hidden_key', because even if it is encrypted it still is storing some form of the info 20:28:33 jbresnah: sorry, i don't think markwash think so...https://etherpad.openstack.org/glance-manipulating-multiple-locations 20:29:31 zhiyan: i am working on swift store for the same, and anyone else is welcome to pitch in for other stores :) 20:30:04 jbresnah: zhiyan: sorry I just need to look again 20:30:38 iccha: cool, i will take look your patch when it ready, and sync though with you...to make sure we are in the same position 20:31:03 thanks zhiyan :) 20:31:06 iccha: I'll take care of GridFS 20:31:13 markwash: sure, but cloud you pls update the doc when you ok, i mean here https://etherpad.openstack.org/glance-manipulating-multiple-locations 20:31:26 iccha: wel, enjoy it 20:31:33 zhiyan: absolutely 20:31:43 zhiyan: is there a specific issue in contention? 20:32:40 markwash: not yet, but seems your thoughts are not the same with jbresnah current did 20:33:26 zhiyan: what i did in which patch? 20:33:39 'locations' content within 'GET /images' result will different... 20:34:28 zhiyan: yeah that patch document is not addressing the metadata 20:34:31 https://review.openstack.org/#/c/31591/ 20:34:36 okay, I see so I just need to make sure that I'm being consistent, and make sure that the guidance in that etherpad and on the reviews is the same 20:34:49 and that way I can stop being a blocker :-) 20:34:50 jbresnah: yes, but not the key 20:35:45 markwash: yes, the key i think is make a final design about PATCH interface for locations updating 20:35:50 cool 20:35:56 * markwash will review and comment :-) 20:36:03 sounds good 20:36:20 i just don't think your thoughts is the same with jbresnah's 20:36:25 right 20:36:35 if it happens when i am gone note that i am very flexable about what the API looks like 20:36:45 i just want metadata to flow back with a location 20:36:50 and perhaps in the future flow in 20:36:50 +1 20:36:52 but that can wait 20:37:44 so if we are looking for a topic, can i address quotas a bit? 20:37:48 sure 20:38:13 markwash: you recall at the summit that keystone people were going to add some functionality to support quotas? 20:38:24 markwash: do you know if anything has happened there? 20:38:40 yes; no I haven't heard anything about progress yet 20:39:25 ok, at one point we thought it would be ok to add a basic config for max allowed storage in bytes to glance 20:39:31 ...or at least i thought that was mentioned 20:39:34 any thoughts on that? 20:40:31 I haven't put many thoughts in quotas (besides our early discussions about the implementation) 20:40:38 I'm not sure its the best fit, but I think it could probably be okay 20:40:51 Have we thought a bit more about how it should be implemented? 20:40:57 ok, i may put some thoughts in code then 20:41:05 it seems like storage quotas could be both broader and narrower than a glance store 20:41:05 sounds good 20:41:13 nod markwash 20:41:24 broader, becuase you might view your e.g. fs store as a shared resource across glance, nova, etc 20:41:35 i am thinking this would be just 1 way to do it that could make sense for simple (which is probably most) deployments 20:41:45 narrower, because you might view your fs store and your swift store as two completely independent storage systems, with different quotas 20:42:16 nod, i agree 20:42:24 cool, well, I'm interested to see some code 20:42:29 +1 20:42:39 ultimately i think it is clear that quotas need to be cross cutting 20:42:50 I'm sure lots of folks would like a 70% solution 20:43:00 right ok cool 20:43:11 anybody want to do another shared review day? maybe sometime next week? 20:43:29 I bring this up and then never schedule it. . . 20:43:29 i would love to do one, but i am out next week 20:43:31 markwash: I won't be around next week. What about the one after next ? 20:43:47 markwash: I'm down for getting my head into some reviews 20:43:56 hmm, that could be better than. . can other folks confirm availability week after next? 20:44:10 +1 20:44:11 . . . / would monday work? 20:44:14 +1 20:44:23 vote ? 20:44:25 :D 20:44:30 you mean july 1? 20:44:37 we never use thouse great features 20:44:40 rosmaita: 8th 20:44:42 I think I mean the 8th 20:44:47 ok 20:44:47 7/8 works for me 20:45:02 I'm a bit late to the party, but I'm out July 4 - 14 20:45:05 works for me 20:45:07 don't let that stop you tho 20:45:28 +1 for 8th 20:45:38 I'm hearing mostly okay, so I'll add that date to my list 20:45:40 and send out reminder 20:45:41 s 20:46:02 I'd love to close it off 15 minutes early today, if that's okay with everyone. . . 20:46:14 got a quick question 20:46:17 go for it 20:46:23 +1 not much to say. I'm catching up with many stuff 20:46:35 kindly reminder again, pls review https://review.openstack.org/#/c/33409 if you ok, thanks :) 20:46:40 was updating some docs, wrote up a page about where the glance docs are source and posted: 20:46:41 * ameade thinks we should sit here in silence for 15 min 20:46:47 https://wiki.openstack.org/wiki/Glance-where-are-the-docs 20:46:52 rosmaita: timely! 20:46:58 ameade: lol 20:47:00 anyway, i was adding stuff about the notifications 20:47:10 someone put a comment that i should include examples 20:47:16 but i am lazy 20:47:28 +1 20:47:28 and also don't think they belong in the "developer" docs anyway 20:47:34 if we end with time an update on async workers would be nice 20:47:35 this is awesome rosmaita 20:47:38 so much xml support 20:47:46 and markdown 20:47:58 rosmaita: really coool 20:48:00 jbresnah: m working on a use case for it 20:48:14 anyway, was wondering what you think about examples in the dev docs 20:48:30 was thinking they'd be better in the operator docs 20:48:38 since they'd be consuming the notifications anyway 20:48:39 markwash: jbresnah stuck on figuring the design logic for transfer of image_data (in the import case) 20:48:45 rosmaita: for notifications, yeah that makes sense 20:49:05 *putting notification examples in operator docs 20:49:07 nikhil: I would be happy to talk that out with you sometime if you think it would help 20:49:15 except, of course there's not an obvious place for notifications in theoperator docs right now! 20:49:26 jbresnah: sure, lemme try to put up a patch tomorrow 20:49:33 nikhil: +1 20:49:36 and we can sync up on glance channel sometime? 20:49:40 I'd like to use your "where are the docs" page as a launching point for re-evaluating the general flow of glance docs, and hopefully directing an effort towards improvement later in havana 20:49:40 flaper87: cool 20:49:50 works for me 20:49:50 nikhil: sounds good 20:49:52 nikhil: make sure to pull me into the loop 20:49:58 flaper87: sure 20:50:36 rosmaita: so for now, we could just add notifications docs to the bug list 20:50:44 ok 20:50:56 then can someone +2 https://review.openstack.org/#/c/33985/ 20:51:31 markwash: i'll add a bug and assign it to myself 20:51:36 am I allowed to nitpick about copyright headers? :-) 20:51:43 sure 20:51:49 what's wrong? 20:51:55 2011-13 :p 20:52:19 markwash: no no no, you can't beat me to it this time :P 20:52:24 lol 20:52:48 I like how now I can pretend that I *did not* nitpick about copyright headers :-) 20:53:01 lol 20:53:03 so is that really it? 20:53:15 pretty much 20:53:20 we don't need a slash 20:53:38 so what should it be? 20:53:49 its either an effectively new document (2013) or you can forgo mentioning the copyright for the recent additions by leaving it as is 20:54:10 what's the consensus here? 20:54:31 since i have to change it anyway 20:54:35 the legal consensus is pretty much that it doesn't matter, but anne did put together something that said "don't bother with hyphenated dates" 20:54:53 OK, missed that. What's the glance dev consensus? 20:55:16 booo copyrights 20:55:22 ameade: +1 :-) 20:55:35 I'm not willing to -1 for copyrights anymore I guess 20:55:40 I already +2'd the change 20:55:54 I'd slightly prefer leaving it alone 20:56:12 but I mostly prefer trying for myself to not be a troll about copyrights 20:56:41 markwash: are planning on auto-generating docs like nova sometime? 20:56:51 nikhil: oh, I don't know much about that 20:56:58 * nikhil feels that a wave of disagreement is coming his way 20:57:13 jbresnah: i'm not sure your position about https://review.openstack.org/#/c/31306/ , seems your PS2-4 are all the same...so can you clear it here, maybe markwash can remove -1 there.. 20:57:13 ah ok 20:57:47 * flaper87 read PS2-4 as Playstation 2 to Playstation 4 20:57:55 :) 20:58:00 ya me too 20:58:05 patch set 2-4 20:58:15 = patch set -2 20:58:22 heh 20:58:23 :P 20:58:28 iccha: LOL +1 for that 20:58:32 now you all are just being silly :-) 20:58:41 markwash: we're trying to keep you around 20:58:51 apparently its working 20:58:53 yeah 20:58:54 :D 20:58:58 zhiyan: i did a rebase 20:59:04 #endmeeting