20:02:04 #startmeeting glance 20:02:05 Meeting started Thu Aug 22 20:02:04 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:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:08 The meeting name has been set to 'glance' 20:02:12 * markwash is a chair! 20:02:22 i though markwash is human 20:02:45 my cats contend that my human-ness is secondary to my chair-ness 20:03:12 howdy 20:03:20 As we all know, the H-3 merge deadline is looming. 20:03:58 So I'd like to focus for the first half of this meeting (if it takes that long) on scheduling all the appropriate followups to merge our outstanding blueprints 20:04:50 #link https://launchpad.net/glance/+milestone/havana-3 20:05:05 Let's talk scrubber refactoring first 20:05:15 oh, I should highlight folks to for proper summoning 20:05:38 markwash: yes, currently IMO the change is ready to you/team review. 20:06:08 It looks like this is pretty close to ready 20:06:27 zhiyan: I just want to sit down with you and walk through what's going on in some of the core scrubber changes 20:06:47 markwash: thanks, actually i'd like this part refactoring can be landed firstly, then to location-status part if i'm not wrong. 20:06:54 so can we schedule that for sometime soon? 20:07:08 markwash: sure, of cause 20:07:28 zhiyan: are you available at 14:00 UTC tomorrow? 20:07:40 oh wait, that's terrible for jbresnah 20:07:47 jbresnah_ that is 20:08:02 sorry i am late! 20:08:03 markwash: ok, 14:00UTC tomorrow. 20:08:06 what is the topic of the meeting? 20:08:22 jbresnah: we are talking broadly about landing h-3 bps, and right now glance-scrubber 20:08:39 i mean the meeting tomorrow 20:08:42 zhiyan: sorry, I realized that's a bad time. would later today work? 20:08:59 jbresnah: final review of the glance-scrubber refactoring 20:09:06 markwash: that's ok to me also :) 20:09:24 even just 1500 is a lot better for me 20:09:26 if possible 20:10:01 sorry, I realized I actually can't tmrw (sigh!) 20:10:04 let's just. . 20:10:36 #action zhiyan and markwash to meet for a walkthrough-review of glance scrubber refactoring, others are welcome, time will be announced in #openstack-glance after this meeting 20:10:45 cool 20:10:47 now 20:10:53 #topic basic quotas 20:10:53 if it has to be at 1400 i can try to make it 20:11:05 jbresnah: aiming for today rather than tmrw morning 20:11:07 and if i cannot i will jsut submarine everything you agreed upon in email later 20:11:14 haha :-) 20:11:19 not really 20:12:13 for basic quotas, review is here: https://review.openstack.org/#/c/37993/ 20:12:29 I started to wade in again, but didn't make it through the current patchset 20:12:47 it looks like there's been considerable back and forth. . does it look like we're getting close? 20:13:07 i think so 20:13:26 2 big issues that people might not like 20:13:31 1) my handling of multiple locations 20:13:45 2) the quota is checked before the upload, and again after 20:13:52 i can explain both 20:14:14 jbresnah: i like them all since i know the root causes ... 20:14:55 #1 is basically the usage is all of a users images times their size 20:14:59 ...not worded well 20:15:40 useage is sum([image.size * len(image.locations) for image in all_users_images]) 20:15:52 which has some drawbacks 20:16:12 but i think the current feeling is that once a location is added to glance, the associated store 'owns' it 20:16:22 this discussion came up when talking about delete 20:16:29 and if that is true, i think it should could 20:16:44 #2 has to happen because we do not always know the size upfront 20:16:52 we could ONLY check after the upload and be safe 20:17:01 the check before is really just an optimization 20:17:08 markwash: make sense? 20:17:16 yes, thanks for the extra info 20:17:32 I notice there isn't any enforcement on adding a location, yet, do you agree? 20:17:34 other than that it is just a simple matter of code ;-) 20:17:54 zhiyan: yes, those are not perfect, but it's workable and do the right things, it's trade off 20:18:14 markwash: that is probably true 20:18:16 zhiyan: oh, seems i'm talking to myself. 20:18:31 markwash: ...it seems so obvious when you say it 20:18:33 sigh 20:18:49 markwash: +1 20:19:32 i should be able to run that through the quota proxy 20:19:33 i think 20:19:45 jbresnah: yes, it might get a little ugly though, fair warning 20:20:07 btw, from the change i fixed a potential image data leak issue: https://review.openstack.org/#/c/42896/ 20:20:10 okay, so it sounds like a little bit more dev is needed there, though more review won't hurt with the current patch 20:20:42 let's move on to the other outstanding bp 20:20:47 #topic protected properties 20:20:53 iccha: o/ 20:21:05 markwash: /o 20:21:14 hemanth_: and me have been working on it 20:21:36 we uploaded first patch yesterday. will do some more refactoring and uplaod more patches today evening/tomorrow 20:21:46 early review and feedback will be much appreciated 20:21:57 might need some iteration 20:22:05 iccha okay cool, so the bp should be in "Needs Review" now? 20:22:20 yes probably 20:22:32 done 20:22:48 all right then 20:23:06 iccha: also could you pls attach the review link to bp page? 20:23:13 I think it would also be great to talk a little bit about async processing 20:23:16 #topic async processing 20:23:43 I'm a little worried because I've seen two conflicting patches show up from venkatesh and from flwang 20:24:01 I'm also pretty eager to avoid landing this feature halfway in havana 20:24:45 I guess maybe we don't have venkatesh or flwang present 20:24:47 markwash: yes, was working there with fie and venkat to push on these fronts 20:24:53 none 20:25:01 i've talked with both today morning 20:25:12 markwash: could you pls paste those two review link to here? 20:25:14 however, dont think flwang knows about venkat's patch 20:25:21 nikhil: I see two ways we could move forward on this 20:25:31 we can have WIP gerrit reviews, that depend on each other 20:26:05 or if you want more flexibility (but also more overhead) you can set up a branch in one of your own github repos 20:26:08 and manage the commits in there 20:26:33 markwash: actually, that's what i'd intended 20:26:47 ad my commits up in persnal repo was a ref point 20:26:53 for both fei and venkat 20:27:13 nikhil: okay, cool. . so then I guess to follow up on that, fei and venkat should either put those reviews as WIP or Abandoned for now 20:27:16 however, fei seems to have submitted the patch so venkat did as well 20:27:23 lol 20:27:24 markwash: gotcha 20:27:28 nikhil: thanks for working with them 20:27:37 zhiyan: I don't have the links on hand one sec 20:27:42 and thanks for the clarification! 20:28:16 markwash: i have a question about our decision to use json blobs in the task objects 20:28:29 brianr: go for it 20:28:37 https://etherpad.openstack.org/LG39UnQA7z 20:28:44 lines 38-43 20:29:17 sorry, guys, in my other meeting right now, will look over after i think :) 20:29:18 just fyi 20:29:32 harlowja: thanks 20:29:40 brianr: i think we knew jays concern going it right? 20:29:42 brianr: it is our intention to disallow search 20:29:49 in** 20:30:05 brianr: if we need search, we can add it and just change the schema as needed 20:30:13 markwash: i think the intent is to allow search on random string 20:30:35 ok, if we think it's not a big deal up front, fine 20:30:40 i just had DB migrations 20:30:51 *hate 20:31:19 brianr: fair 20:31:27 this would certainly be a terrible migration 20:31:41 does there seem to be a need to search for tasks based on their input arguments? 20:31:59 ameade: I dunno, there have been several similar keystone migrations, and I'm not sure they were the end of the world 20:32:26 we thought it would help searching for tasks markwash 20:32:31 well it's got to do with idempotence, i guess 20:32:35 in case of multi-tenant 20:32:45 or rather multi-user in single tenant 20:34:10 I guess I don't follow 20:34:15 don't know whether we care about 5 imports of the same image or not, really 20:34:33 it seems like the number of tasks wouldn't be very large in general? since we expire them. . . 20:34:39 s/image/image data/ 20:35:13 well, okay… we might need to sync up again 20:35:31 well, maybe not, the only reason i'm worried is DB migration 20:35:38 markwash: yes, actually fei also wanted to 20:35:39 several issues here seem to be pushing back against generalizing imports/exports/clones to generic tasks 20:36:06 we need to sync up on interface between async and tasks api 20:36:06 but OTOH, taskflow generalized much more to tasks 20:36:06 ok, well better to talk than not talk 20:36:29 so josh had to leave, but what do you think about taskflow? 20:36:37 for image import, i mean 20:36:49 I think it looks very relevant, the question is where is the seam for integration? 20:37:00 exactly 20:37:16 +1 20:37:21 we should find a time to meet about that where we can include harlowja 20:37:29 my thought is to do import, see what taskflow delivers in havana, and reconsider when we do export and clone 20:37:32 :) 20:37:33 because I want to make sure we're incorporating the correct spirit of taksflow 20:37:33 up for it 20:37:40 we should have more domain knowledge at that point 20:37:43 who scheduled taskflow weekly meeting and glance one at same time, haha 20:37:52 * markwash hides 20:38:09 okay, there's another bp I wanna talk about quickly 20:38:19 can you guys coordinate another meeting? 20:38:39 I wanna be there. . but my mother in law is coming to town too. . so 20:38:44 :-) 20:38:56 my schedule is a bit uncertain right now 20:39:04 brianr: ^^ 20:39:20 so is tomorrow out of the question? 20:39:27 I can't do morning 20:39:40 I could swing this time, but that probably doesn't work for fei 20:40:09 fei and i wanted to sync up with some of the folks here 20:40:19 sometime probably early next week 20:40:22 okay let's just coordinate through email then 20:40:40 who is doing that? 20:40:47 i meant 20:40:49 ok, maybe monday at 15:00 again? 20:40:55 anyone doing that or shoud i? 20:41:13 brianr: that may be tricky for fei 20:41:16 one of you two should :-) 20:41:24 but sure if you think :) 20:41:27 markwash: ok sure 20:41:29 #topic openstack common notifier 20:41:42 i meant whatever time we met the other day, it worked for fei 20:41:44 so, this has come back up, again for support of ha rabbit setups 20:41:58 review https://review.openstack.org/#/c/37511/ 20:42:16 and a followup https://review.openstack.org/#/c/43319/ 20:42:24 I'd just like to request more eyes on that 20:42:33 it looks like we can land this in H-3 without being disruptive 20:43:11 but in particular I want some review of the config changes--want to make sure it won't cause problems for deployers 20:43:20 there is something about patches that port to oslo that make me afraid to review 20:43:34 i will take a look at them soon 20:43:44 I walk into those with some concerns as well 20:44:10 isnt flavio core on oslo now? 20:44:13 in light of a recent ML discussion, I think it makes sense to be very careful about oslo-incubated libraries until they're released on their own 20:44:21 lets make him do it :-P 20:44:35 basically, it looks like the kind of refactorings that make me really happy don't happen until the oslo libs are released :-) 20:44:47 oh right, that brings up that one issue of adding an oslo aphpa to requirements 20:45:11 it seems to me that it makes sense to only use them after release 20:45:13 so I just want glance-core to keep in mind that its a totally viable strategy to adopt common code once its refactored and re-released. . we don't always have to be early adopters on oslo-incubator 20:45:20 an i really dont like the copy-code-in model 20:45:31 jbresnah: as a default, I agree, but I do think it makes sense to participate early sometimes 20:45:34 and it can save some effort 20:45:45 yeah i see that 20:45:53 that code has to get used somewhere before it's a library 20:46:00 i am just giving all of my excuses as to why i am bad about oslo reviews 20:46:01 jbresnah: I checked on the oslo alpha dependency in the project meeting this past week 20:46:02 but i agree 20:46:14 and its apparently all good 20:46:26 jbresnah: I was doubly reassured by markmc that its not a problem at all 20:46:51 lets' talk client! 20:46:56 #topic glance-client 20:46:59 i bugged one of our deployment guys and he said it shouldn't be an issue, esp since it's already in nova 20:47:23 ameade: cool good to know! 20:47:44 that fact probably translates to just about everybody else too, if its already in nova 20:48:31 I'd like to release a new client 20:48:37 0.11.0 20:48:53 this will pick up the PBR changes, which might mean packaging changes for some folks working on a fork 20:48:57 is create in the CLI for v2 yet? 20:49:04 jbresnah: there is a review for that 20:49:08 I have a patch for that 20:49:11 cool 20:49:13 https://review.openstack.org/#/c/42741 20:49:17 once that is in i would love to see a release 20:49:31 jbresnah: I agree. . but it might be 0.12.0 20:49:45 and then shortly after that, I'd love to release 1.0.0 20:49:53 ok 20:50:01 markwash: but 1.0.0 means bugs actually count! 20:50:06 this is something folks need to be thinking about, because its a rare opportunity to delete old stuff we don't want to support 20:50:07 if they can be done quick and easy then no sense waiting 20:50:08 ameade: lol 20:50:10 markwash: the packaging chanegs might not affect us (not 100% on this though) 20:50:15 heh ameade 20:50:32 so, things I know to be on the chopping block for 1.0.0 compatibility breaking 20:50:36 markwash: can we get ride of everything deprecated then? 20:50:41 jbresnah: +1 20:50:43 nice 20:50:45 also, the legacy shell 20:50:48 lets get rid of v1 20:50:49 lol 20:50:52 heh 20:51:01 it ll be good to get eyes on esheffield 's patch 20:51:09 esp with the way its dealing with schemas 20:51:10 iccha: I think this is the right opportunity to change the default # of results per list 20:51:12 iccha: I will do that for sure 20:51:24 iccha: i need to make the client reviews part of my day also 20:51:39 the whole time I've been working on it I kept seeing stuff I wanted to delete ;-) 20:51:47 markwash: not sure what you mean 20:52:08 nikhil: hmm. about what exactly? 20:52:21 default # results for list? 20:52:33 hope that does not have to do with page size 20:52:34 i have to run a bit early 20:52:40 that patch taht was reverted right? 20:52:41 nikhil: earlier, there was a change in glanceclient to go from 20 to 100 on the page size 20:52:47 yes 20:52:58 and I thought that change would break backwards compatibliity, so I pulled it from the 0.10.0 release 20:52:58 and we've a new patch up in nova 20:53:08 okay cool 20:53:09 which will send it as a param to glance client 20:53:15 so maybe you're not worried about this anymore. . fine by me :-) 20:53:29 but still i think it ll be good to up the limit anyways 20:53:30 markwash: yes, saw your ping on the channel and we noted it. thanks! 20:53:51 i thought it broke stuff for people 20:54:00 if the release help then it's okay 20:54:28 again, so the takeaway is just "Think about the things you want to see removed from glanceclient, because we get the chance to break (some) backwards compatibiity soon!" 20:54:44 to be clear, we need to keep the basic interfaces of the v1 and v2 client in place 20:55:02 darn 20:55:06 :-) 20:55:10 #topic open discussion 20:55:49 important bugs 20:55:50 https://review.openstack.org/#/c/40619/ 20:56:06 https://review.openstack.org/#/c/42896/ 20:56:22 there might be others, but those are the high importance ones I see target to H-3 20:56:54 3.5 pages on glance + glanceclient reviews....and this is esp my bad for not reviewing much lately 20:57:18 its my bad as well 20:57:26 but we have to consider stability important at this later stage 20:57:32 we might get help from some ghosts 20:57:51 think ameade knows what i mean 20:58:06 so if a review comes in with a feature change, at this point it might make sense to -2 defer to Icehouse 20:58:52 okay thanks everybody 20:58:57 #endmeeting