13:59:05 #startmeeting glance 13:59:06 Meeting started Thu Jan 21 13:59:05 2016 UTC and is due to finish in 60 minutes. The chair is flaper87. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:06 #topic agenda 13:59:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:59:07 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 13:59:09 The meeting name has been set to 'glance' 13:59:27 hi o/ 13:59:36 o/ 13:59:37 o/ 13:59:38 o/ 13:59:40 o/ 13:59:41 o/ 14:00:00 That's our agenda, as usual. Please, add new topics at the bottom if there are things you'd like to talk about 14:00:18 rosmaita: jokke_ ? 14:00:32 o/ 14:00:43 nikhil: ? 14:00:44 #topic Updates Artifacts 14:00:51 mfedosin: ativelkov floor is yours 14:01:07 I promised I would attend the artifacts meeting on Monday. I failed! 14:01:15 * flaper87 is a terrible terrible person 14:01:21 So did I :( 14:01:22 I swear I have a good reason 14:01:27 o/ 14:01:31 #chair rosmaita mfedosin 14:01:32 Current chairs: flaper87 mfedosin rosmaita 14:01:43 just in case my network goes south 14:01:49 ativelkov: any news from artifact's land? 14:01:50 o/ 14:01:58 We don't have much to update, since mfedosin was primarily busy with nova stuff 14:02:12 Sorry the spec hasn't been approved yet. I'd like to see some comments from sigmavirus24_awa and then we're good 14:02:30 Since the Public API spec is in a good shape, we hope to get its first implemenation in several days from now 14:02:34 ativelkov: that's good news ( mfedosin being busy with nova, that is) :P 14:02:45 * flaper87 wants to get that nova stuff done. NOW! 14:02:46 :P 14:02:54 ativelkov: sounds promising 14:03:02 Same do I, so no rush, nva is more important for sure 14:03:07 nova* 14:03:23 Also, I did couple of more reviosions to the v3 -> v0.1 migration patch 14:03:29 minor nits mostly, plus rebase 14:03:31 * flaper87 does a wolves dances around a campfire to make sure the nova work will be completed 14:03:36 now, picture that ^ 14:03:38 one more rebase seems to be needed though 14:03:41 * flaper87 stfu 14:03:51 ativelkov: that one is on my review queue for today 14:03:59 cool, thanks! 14:04:22 moving on, unless there's more 14:04:42 Also we had a conversation with docaedo from comunity-app-catalog team, they want to start prototyping their glare-based backend soon, so the public api will be handy there 14:04:43 #topic Updates Drivers 14:04:48 ops 14:04:54 * ativelkov is done 14:05:03 ativelkov: that's good news 14:05:18 ok, not much from our side either 14:05:25 we've reviewed the SFE requests 14:05:35 3 (or 2?) have landed already 14:05:40 one is left to review (glare's) 14:05:48 but we'll get to it before the end of the week 14:06:03 it seems that gate is broken 14:06:08 Some spec lite were triaged 14:06:08 and now those patches can move forward 14:06:18 mfedosin: why? why? why do you have to do that to me? WHY? 14:06:27 * flaper87 runs around the team crying desperatedly 14:06:36 mfedosin: mmh, do we know the reason? 14:06:39 hi 14:06:43 I'll take a look after the meeting 14:06:50 o_O me? 14:06:59 that's it! 14:07:01 #topic Updates Nova v1 -> v2 14:07:03 flaper87, see [openstack-dev] [devstack] pip 8 no longer over-installs system packages [was: Gate failure] 14:07:04 mfedosin: yours 14:07:20 kairat: so, it's not just glance.... phew 14:07:25 yep 14:07:36 flaper87: we don't break things :P 14:07:36 i think anything that uses argparse 14:08:18 mfedosin: so, v1 -> v2 14:08:18 sabari: lol 14:08:19 okay... no big updates, but several big agreements are here 14:08:35 first, we decided to cache glance version 14:08:48 and do not request it each time 14:09:03 nice 14:09:04 and also reload on SIG_HUP 14:09:10 Jay was against it, right? 14:09:13 gotcha 14:09:13 sounds good 14:09:19 it will simplify the code dramatically 14:09:46 also I updated compat patch in glanceclient 14:09:56 so, please review it :) 14:10:10 will review. Did you address jokke_'s and my comments? 14:10:14 https://review.openstack.org/#/c/266419/ 14:10:19 yes 14:10:30 We'll have to discuss it a bit further to reach consensus on what the direction should be 14:10:31 coolio 14:10:34 anything else? 14:10:46 also I have a couple of suggestion that may help in this work 14:11:02 but I'm going to talk about it later today 14:11:14 xenplugin: 14:11:27 I will remove explicit status updated 14:11:40 ok 14:11:42 since it's not required 14:11:50 #topic FYI https://review.openstack.org/#/c/270752/ (flaper87) 14:11:57 #link https://review.openstack.org/#/c/270752/ 14:12:00 That's M-2's tag 14:12:38 We were ready to tag on Tuesday but there's a sec fix on going that we wanted to wait for. It couldn't make it in time so the tag has been done w/o it 14:12:52 I'm saying that because the review effort was AWESOME! 14:12:58 thanks to everyone who jumped in 14:13:09 this tag contains several bug fixes for 500 errors 14:13:14 and a couple of other things 14:13:21 (IIRC, btw) 14:13:22 :P 14:13:35 questions? thoughts? 14:13:52 we probably should look into releasing store as well soon enough 14:14:04 to have common point for testing those two together 14:14:15 yeah. I'd like to hold off glanceclient until the compatibility layer lands, though. 14:14:18 ++ 14:14:36 Let's work together on getting glance_store out next week 14:14:36 as a bridge to that 14:14:48 #action jokke_ and flaper87 to release glance_store next week 14:14:54 do we have topic for the metadef subcommanding? 14:15:09 in todays meeting? 14:15:10 don't think 14:15:30 ok, if we are going to do that we need to time it smart release wise 14:15:36 ok, moving on 14:15:49 pls add a topic :D 14:15:55 for today's meeting or next week's 14:16:13 #topic Re-think the Glance Drivers team 14:16:17 #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/084562.html 14:16:28 who had time to read that email before the meeting? 14:16:34 me 14:16:44 Yes. Let's do it. It's been waiting for a while. 14:16:48 From the email: Gonna cut the chase: I think we would do a better job on the specs (and light 14:16:50 specs) side if we get rid of the Glance Drivers team and encourage everyone 14:16:51 (especially from the core team) to weight in. 14:16:52 Would be good to try 14:16:52 " 14:16:53 i think it makes sense, particularly wiht the spec-lite process 14:17:10 me 14:17:19 you 14:17:23 agree, spec lite is a bit too decoupled to triage 14:18:00 ok, I'll start working towards that. We'll still have a driver's meeting next Tuesday and I'll present a more formal proposal with a plan forward 14:18:08 ++ 14:18:33 w000h0000! 14:18:41 ok, if there are no objections, I'll move on 14:19:14 #topic https://bugs.launchpad.net/glance/+bug/1535900 (spec-lite for a new disk_format value) (rosmaita) 14:19:17 #link https://bugs.launchpad.net/glance/+bug/1535900 14:19:18 Launchpad bug 1535900 in Glance "Add tar as a disk_format to glance" [Wishlist,In progress] - Assigned to Arun S A G (sagarun) 14:19:25 rosmaita: 14:19:34 yeah, so in the spirit of flaper87's email, i wanted to bring this up at the meeting 14:19:46 two questions, basically: 14:19:57 (1) tar as a disk_format vs container_format 14:20:11 (2) how to keep the image plugin for glare in sync with glance 14:20:34 the patch for the spec-lite does the code change in the artifact plugin, not glance 14:20:45 by mistake 14:21:11 anyway, if you have an opinion, please comment on the spec-lite 14:21:21 mmh... so, I think we should put some extra reviews in the glare migration to get it done asap 14:21:23 that's one thing 14:21:32 re (1), I'm also torn there, TBH 14:21:35 I don't think the decoupling between the two is problem as long as the artifacts API is still considered as experimental 14:21:38 To me, it's a container 14:21:49 I wouldn't want to worry about keeping them in sync particularly and mark any lags in improvements under special tag for bugs in LP 14:22:08 me too, but its a weird case ... i asked for clarification, so we'll see 14:22:33 from the bug: "There is no metadata in the tarball. By OS tarball i mean it is a compressed tar archive of a / (root filesystem)" 14:22:40 that's in reply to your comment 14:22:50 yeah, it's interesting case 14:22:53 I guess it could be either, tbh. 14:23:03 Can this be brought up in the mailing list? 14:23:04 can the disk be considered raw and container tar in this case? 14:23:11 yeah, so we need to decide what makes the most sense 14:23:14 I think we could benefit from feedback from other teams 14:23:17 ML is a good idea 14:23:20 Nova and Ironic, FWIW 14:23:28 s/FWIW/For example 14:23:36 * flaper87 can't acronym 14:23:41 rosmaita: want to take that task on? 14:23:42 cinder too I think 14:23:47 flaper87: will do 14:23:53 rosmaita: ++ 14:24:06 #action rosmaita to send an email requesting feedback on whether tar should be considered a container or a disk format 14:24:25 anything else? 14:24:29 Anyone ? 14:24:48 * flaper87 is still thinking about container vs disk format in the back of his head 14:24:55 #topic Implement purge_props flag in v2 image-update (part of Nova v1 -> v2 initiative) (mfedosin) 14:25:01 mfedosin: go go go 14:25:10 okay, it's me again 14:25:38 as you may know there are inconsistencies in removing props in v1 and v2 14:26:04 in v1 you have to provide purge_props flag to image-update 14:26:27 and if it's true then all unlisted properties in values will be removed 14:26:49 in ve you have to provide list of prop you want to remove 14:27:03 in remove_props param 14:27:11 * flaper87 likes v2's way of doing things 14:27:26 Nova uses v1 and passes purge_props flag 14:27:44 it's pretty easy to implement this on Nova side 14:27:55 here's the example how I do it http://paste.openstack.org/show/484572/ 14:28:01 doesn't nova always set purge_props false? 14:28:22 rosmaita, no 14:28:33 ok 14:28:41 at least there are several tempest test that fail 14:28:49 TBH, this is one of those cases where we can move Nova to v2 with a workaround on nova side 14:29:00 one of the things I'd like to see gone and not in the compat layer 14:29:11 I want to implement this in glance client 14:29:19 (support of purge_props) 14:29:27 If we can do it in nova, let's do it there. 14:29:37 as you may see we make additional 'show' call 14:29:53 to fetch all current properties 14:29:58 * jokke_ does not like the idea of having "Oops, I killed everything" flags around 14:30:05 right, that's one reason I think we shouldn't add it in the compat layer 14:30:13 jokke_: exactly my feeling 14:30:23 I had to remove some propos yday using an old glanceclient 14:30:32 I ended up doing it in mysql directly 14:30:39 I don't trust purge_props 14:30:39 :P 14:30:41 flaper87, lol 14:31:08 but it complicates the workflow 14:31:08 mfedosin: has anyone from Nova complained aout that piece of code? 14:31:22 tempest complained 14:31:38 * flaper87 kicks tempest's ass 14:31:43 why? 14:31:49 what did it complain about? 14:32:02 ah, no 14:32:08 no one complained 14:32:19 ok ok 14:32:20 cool 14:32:22 I thought about tests failing 14:32:39 but if we leavi it in Nova then we will do additional 'show' call 14:33:16 if it's okay, then let's do it like now 14:33:26 ok 14:33:33 thanks 14:33:33 if there's a bigger complain, do let us know 14:33:39 sure 14:33:54 #topic Incorrect glance v2 API behavior ( mfedosin) 14:34:03 yes, it's mine again 14:34:03 #link http://developer.openstack.org/api-ref-image-v2.html 14:34:25 me and Stuart found a wrong behavior in v2 14:35:09 if image contains no data then glance has to return 204 code after image-download 14:35:30 but now it's 200 and glance creates an empty file 14:35:33 mmh, is that during downloads ? 14:35:40 yes 14:35:50 uploads work fine 14:36:05 so, you're saying: When I try to download an image and there's no data, I get 200 14:36:05 if we don't provide data then glance returns 204 14:36:24 flaper87, correct 14:36:31 by no data you mean the file is empty or there hasn't been an actual upload? 14:36:39 mfedosin: which one? 14:36:39 :P 14:36:46 empty file? 14:36:46 or no upload has been done? 14:36:56 this one so, you're saying: When I try to download an image and there's no data, I get 200 14:37:01 because, if the image is active and the file is empty, there's no way for glance to know that 14:37:26 if the image is queued and I try to download an image, then prob 204 (or error?) should happen 14:37:31 mfedosin: when you say "no data" do you mean 0 byte file? 14:37:41 rosmaita, yes 14:37:56 I think this is a bug 14:38:02 and not incorrect behavior 14:38:12 the checksum should fail 14:38:14 mfedosin: so there is a location set, it just has 0 bytes? 14:38:27 for an "active" image with 0 bytes 14:38:28 location is set, right 14:38:33 nikhil: good point about the checksum 14:38:41 and glance creates a file in store 14:38:58 so, it's a bug in the upload path 14:39:01 ? 14:39:14 as in, allowing uploads of empty files is not really what we want 14:39:20 or 0-sized files 14:39:26 s/files/images/ 14:39:43 here's the paste http://paste.openstack.org/show/484577/ 14:39:44 It would be good to know who really needs a 0 byte file. Else, we need to fix this corner case. 14:39:56 nikhil, AFAIK nova 14:40:00 there was discussion around this topic in ML I think 14:40:05 nikhil: there's a not so old thread about this in the mailing list 14:40:12 ah ha 14:40:14 there's a use cause for it in nova, that I don't fully agree with 14:40:16 scolling 14:40:19 the problem is that nova relies heavily on that behavior 14:40:31 flaper87: ++ 14:40:54 I still think this is wrong and there should be a different way to do this from nova 14:40:58 and what's happen during download http://paste.openstack.org/show/484578/ 14:41:24 lol @ file "lalala" 14:41:30 * flaper87 notices mfedosin likes to sing 14:41:49 so IMO if we allow 0-size image to transition the image to active the output needs to be 0-size image file ;) 14:41:58 flaper87, You saw through me 14:42:16 jokke_: ++ 14:42:34 then we have to update api specification 14:42:47 WE FOUND THE BUG! 14:42:52 it's in the specs 14:42:52 :D 14:42:54 OMG 14:42:56 * flaper87 dances 14:43:06 * mfedosin sings 14:43:17 does anyone disagree with the above? 14:43:17 rosmaita: nikhil ? 14:43:24 i am confused by the paste 14:43:25 where's mclaren? 14:43:44 rosmaita: first paste creates an image and uploads an empty file 14:43:44 sencond paste downloads it 14:43:44 he's one how found it 14:44:03 the point mfedosin is making is that the second paste shouldreturn 204 14:44:20 I'd argue that 200 is correct becuase the image resource *does* have a file 14:44:23 it's just empty, which is not glance's problem 14:44:36 that's correct 14:44:38 rosmaita: does that make sense? ^ 14:44:38 sorry was looking at wrong one 14:44:43 but I think we should check RFC 14:44:46 * flaper87 roflk 14:45:01 will wait for sigmavirus24_awa's input 14:45:04 yes, if it does have a file, shoudl return 200 and file content 14:45:11 whcih is nothing in this case 14:45:14 yup, sigmavirus24_awa input would be cool 14:45:23 right 14:45:28 I am a bit torn on this idea 14:45:32 sigmavirus24_awa: ^ pls, read backlog and provide feedback 14:45:33 I think the problem is bit vague explanation in the API reference 14:45:37 anyways, will wait for sigmavirus24_awa 14:45:47 "If no image data exists, the call returns the HTTP 204 response code. " 14:46:01 Are we going to create empty file in nova case? 14:46:18 kairat, seems so 14:46:24 Hmm 14:46:30 I guess so 14:46:38 they promised to fix this behavior 14:46:41 so looking that reference the assumption indeed is that we return 204 if the image size is 0 14:46:45 I don't like the idea but to prevent that we'll have to forbid 0-sized files 14:46:48 with empty images 14:46:52 which breaks the API 14:47:06 mfedosin: could you update the API reference? 14:47:11 ++ 14:47:15 we can get sigmavirus24_awa review there 14:47:15 okay 14:47:20 IIRC, when glance_store throws NotFound we return a 204 14:47:39 https://github.com/openstack/glance/blob/master/glance/api/v2/image_data.py#L304 14:47:42 that would be compat with the API ref 14:47:50 yeah, but in this case it won't raise NotFound 14:48:05 sabari: what nikhil said ^ 14:48:12 that's lunatic as well 14:48:22 right you are jokke_ 14:48:36 why do we returnn 2XX if backend returns NotFound 14:48:40 yeah so that's out defintion of no image data :) 14:48:48 and yes only error condition listed is 403 14:48:55 I would prefer not to create empty file 14:49:01 horrible 14:49:02 in store 14:49:13 ok, 10 mins left. Would like to have some time for Open Discussions 14:49:13 #action mfedosin to update the API ref 14:49:36 #action sigmavirus24_awa to attend meetings and review mfedosin patch 14:49:38 :P 14:49:47 #topic Open Discussion 14:49:55 Gooooooooo Crazy! 14:50:00 hi, https://review.openstack.org/#/c/261288/2 is about request-id using hooks 14:50:06 shoot all your open questions 14:50:28 i have implemented as per stuart and jokke_'s suggestion 14:50:45 need early reviews ^^ 14:51:22 abhishekk: ++ 14:51:22 will review 14:51:25 What do we do about this https://review.openstack.org/#/c/218864/ 14:51:30 i know m2 is near but when you get time please review 14:51:46 abhishekk: m2 is out 14:51:59 flaper87: thank you, great 14:52:12 For reference TC approved priority change to osc instead of individual project clients 14:52:39 jokke_: IMHO, we should have one last CLI release where we can fix some things, clean some others up and freeze it 14:52:54 flaper87: ++ 14:52:55 flaper87: Nice basis for fork? 14:52:59 s/priority change/cross-project spec/ 14:53:15 jokke_: not my fork ;) 14:53:32 seriously, I know you don't like OSC 14:53:46 but pleeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeease, don't do crazy stuff 14:53:46 :P 14:53:56 not me 14:54:04 ok ok ok 14:54:07 * flaper87 hugs jokke_ 14:54:13 it's the rest of the vocal community 14:54:41 I'm just trying to preserve last bits of sanity :P 14:54:49 we'll see how many forks come out of this 14:55:12 I hope len(forks) == len(projects) 14:55:15 I don't think there will be (many) but that's my perception 14:55:28 * nikhil need to run. 14:55:30 thanks all. 14:55:39 jokke_: FWIW, ppl could have done the same with current CLIs if they didn't like them 14:55:41 but ppl didn't do that 14:55:52 so, why should the same happen with OSC ? 14:55:55 anyway, that's just my opinion 14:56:01 good thing this is Open Discussion 14:56:01 but 14:56:05 2s 14:56:07 flaper87: true ... telling that people have been happy with the clients provided 14:56:10 ;) 14:56:26 before we start insulting each other, as we normally do, let's stop and not do it here 14:56:32 ++ 14:56:53 :D 14:56:57 * flaper87 hugs jokke_ ... again 14:57:16 ok, that's it folks 14:57:20 but that does not remove the question is that large refactoring warranted at this situation 14:57:25 pls review) https://review.openstack.org/#/c/248359/ 14:57:29 *hugsback* 14:57:47 dshakhray: ++ 14:57:49 THANKS FOLKS! 14:57:51 yes folks, please review Darja's code https://review.openstack.org/#/c/248359/ 14:57:52 have a good one 14:57:57 and an even more awesome weekend 14:58:00 mfedosin: ++ 14:58:03 o/~ 14:58:04 #endmeeting