14:04:39 #startmeeting glance 14:04:40 Meeting started Thu Oct 11 14:04:39 2018 UTC and is due to finish in 60 minutes. The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:04:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:04:43 The meeting name has been set to 'glance' 14:04:43 #topic roll call 14:05:05 I guess something is wrong with erno's calendar 14:05:08 hello abhishekk and LiangFang 14:05:08 o/ 14:05:14 o/ 14:05:23 hi sean 14:05:23 hi 14:05:30 Morning rosmaita 14:05:39 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:05:43 Hi Sean 14:05:45 hi 14:06:07 Hi all! :) 14:06:08 we'll let jokke_ do updates when he arrives 14:06:15 let's skip to item 2 14:06:23 #topic release updates 14:06:35 periodic jobs are all green for all products! 14:06:37 o/ 14:07:06 \o/ 14:07:13 just want to mention the update to the zuul-web interface has broken my bookmarks, possibly yours too 14:07:23 fix is on the agenda 14:07:32 new interface is nice, though 14:07:44 Yeah, looks a lot cleaner. 14:07:49 ok, actual release info 14:07:57 Stein-1 is in 2 weeks! 14:08:28 i copied the Stein-1 stuff from the ptg into this etherpad 14:08:36 https://etherpad.openstack.org/p/glance-project-releases 14:08:54 but we should probably discuss what's in there when jokke_ gets here 14:08:56 I am having tough time to understand new zuul :( 14:09:09 i have only looked at the builds page! 14:09:20 is the status page not so good? 14:09:55 I think it's pretty much the same, just updated the look of it. 14:09:56 It doesn't filter now on mobile browser now 14:10:04 Ah, hadn't tried that. 14:10:09 abhishekk: you need better work/life separation! 14:10:15 Hah@! 14:10:18 :D 14:10:31 speaking of which, i need to step down as Glance release CPL 14:10:40 and i nominate abhishekk to do it, if he is willing 14:10:59 rosmaita, I will 14:11:06 Great! 14:11:21 excellent! https://docs.openstack.org/glance/latest/contributor/release-cpl.html 14:11:58 rosmaita, thanks 14:12:01 ok, hopefully jokke_ will be here soon to talk about S-1 milestone 14:12:14 let's move to item #3 14:12:22 LiangFang: that's you 14:12:34 #topic image size BP 14:12:38 OK 14:13:06 when upload volume to image, glance backend will have to resize 14:13:12 except lvm 14:13:30 so it will be some performance issue 14:13:45 I have 2 though about this 14:14:03 first one is this BP 14:14:33 cinder calculate the image size and send to glance via http header 14:15:02 another solution is: 14:15:15 I think this is the bp https://review.openstack.org/#/c/608400/ 14:15:38 when upload, there will be 2 steps, first is create image, second is upload data 14:16:28 we can update image size just after creating image, but before upload data 14:16:36 here 14:16:48 i see, so your idea is that you will pass a header wiht the data upload 14:16:49 sorry, connectivity issues 14:16:51 the BP is the first solution 14:17:00 yes 14:17:35 the second solution means Cinder needs to update the size of an image when the image is in queue status before uploading data chunks 14:17:36 pass the size with the data in one request 14:18:03 @lixiaoy1 yes 14:18:10 Can some of that be handled in the glanceclient code? 14:18:25 i didn't like the header solution at first, but i think it's not that bad 14:18:57 @sean, do you mean calculate the size in glanceclient? 14:19:05 currently once an image is created, its size can't be updated. We can transfer size through glanceclient, but inside logic doesn't allow the update 14:19:33 s/transfer size/update size/ 14:19:46 yes, image size is read only via update api 14:19:48 i think with v1 gone, users can never update size now 14:19:58 or set it at all 14:20:05 yes 14:20:11 rosmaita, yes 14:20:12 Yeah. Just thinking rather than cinder needing to be updated to handle that, and any other user of glance, if the glanceclient code can determine the size and send it, then everyone automatically gets the improved performance once they upgrade to that release of glanceclient. 14:20:54 @rosmaita can we update the logic to allow update size when an image is in queue state and its size is 0? 14:21:25 possibly 14:21:32 but also possibly not 14:22:15 @sean, but glanceclient seems cannot know the size by itself 14:22:38 So there was some quite strong arguments why we did not allow setting the size in V2 API I just can't remember what was the problem with that. rosmaita can you recall the reasoning? 14:22:40 the size depend on the format 14:23:53 I understand once the image is avaible, it is dangerous to update size. But when an image is in queue state, it is just created and hasn't be uploaded data 14:24:00 @erno, yes, it makes sense the image size is read only when image already uploaded 14:24:04 that should be safe 14:24:10 LiangFang: that's not the case. The size property is the actual size of the image virtual_size is what ever hypervizor shows to the guest vm as a size 14:25:01 and I don't think there is any thing using virtual_size anymore since V2 14:25:08 *anything 14:25:16 yes, here the size conveyed is just the actual size which glance store use this 14:25:57 i don't think anything has ever used virtual_size 14:26:21 glance store use this actual size to allocate image 14:26:52 rosmaita: with v1 API there was at least way setting it, now I think it's 100% dead weight in the db 14:28:39 I did a poc, in the update api, check the image status and size, and decide if update size can go or not. this works fine 14:29:40 if you guys accept solution 2, i can send my poc to review 14:30:14 #chair jokke_ 14:30:15 Current chairs: jokke_ rosmaita 14:30:17 in sulotion 2, no changes needed in glanceclient 14:30:33 and no api changes 14:31:00 LiangFang: if you have it ready to go, submit it to review and flag it as WIP, please ... at least we have the changes to test it and see the behavior 14:31:03 i don't remember the reason not to set size, i guess it's a user-friendliness thing, that you might get it wrong and then any code that actually checks the download will fail 14:31:06 but need to update image size when it's status is queue and size is 0 14:31:12 same as checksum 14:31:51 rosmaita: I think there was that and it might have been that if the size did not match with the data actually uploaded we killed the image as well so the user had to start from the scratch 14:32:08 right 14:32:10 right 14:32:32 OK, so it's safe to update size when status is queued and size is 0 14:32:44 :) 14:33:04 this is the only window people can update size 14:33:51 LiangFang: yeah, we need to play with that a bit and see how it behaves. Say what happens when you set the size wrong vs. the data you provide 14:34:04 OK 14:34:22 so i will send out my solution poc to review 14:34:34 *solution 2 poc 14:34:40 thanks 14:34:50 lets move on before we run out of time 14:34:50 thanks erno and all:) 14:34:58 ok 14:34:59 jokke_: we need to discuss S-1 milestone 14:35:13 also, before you arrived, abhishekk agreed to become release CPL 14:35:31 rosmaita: yeah, cool 14:35:47 #topic location validation_data 14:36:18 rosmaita: this is you as well. How is the situation looking with the json-patch stuff 14:36:21 ? 14:36:32 good 14:36:39 new spec is up 14:36:52 https://review.openstack.org/#/c/597648/ 14:37:05 it's what iain and i worked out on the etherpad 14:37:17 nice 14:37:32 i like it, i put a comment on the spec for other reviewers to note 14:38:02 about requiring all 3 of checksum and os_hash_* 14:38:03 #action abhishekk smcginnis jokke_ to review the new spec s we can move this forward 14:38:07 just a question, why os_hash_algo max length is 64? 14:38:44 is it as per db length? 14:38:57 Did we want rosmaita's comments addressed first? 14:39:20 got it 14:41:36 if there is nothing else that needs attention about this now, lets continue this on the review and move on to the S-1 release discussion 14:41:47 yes 14:41:56 #topic Stein-1 14:42:13 #link https://etherpad.openstack.org/p/glance-project-releases 14:42:17 So we have 2ish weeks until Milestone 1 14:42:24 i copied the stuff from the ptg into that etherpad 14:44:02 i can put together the ops survey about default viz is you like 14:44:19 *if you like 14:44:34 great 14:44:43 rosmaita: lets do it together. I better get the grasp how to do those 14:45:03 so we have some consistency and don't need to rely you doing it every time 14:45:27 maybe a video meetup? you, me, abhishekk, anyone else who's interested? 14:45:36 (I mean there is consistency on what I do with what you have used to do with them before) 14:45:48 ++ 14:46:13 rosmaita: sounds good ... lets schedule bluejeans for that. Any days you guys would prefer? 14:46:26 how is tomorrow ? 14:46:52 rosmaita, jokke_ as per your preference 14:47:33 abhishekk: how would 13:00 UTC work for you? 14:47:36 tomorrow is fine as long as we are done by 1400 utc 14:48:02 rosmaita, let me check 14:48:14 ok, or 12:00 even 14:48:26 rosmaita, 13:00 works for me 14:48:36 1300 sounds good 14:48:40 ok, great 14:48:55 i will send an email to ML in case anyone else is interested 14:49:16 #agreed User survey meeting on bluejeans tomorrow Fri Oct 12th @13:00 utc. Ping jokke_ for meeting link 14:49:52 remaining/wip for s-1 is glance devstack fix 14:50:19 I'll throw the link on the #openstack-glance channel before we start tomorrow 14:50:26 great 14:50:43 yeah, what's up with the devstack situation? 14:51:21 in PTG we have decided to deploy glance as standalone service 14:51:56 so i think the patch i have up will do that 14:52:18 So I think it's still hanging on the same state it was last cycle when you put the patch up and it wasn't accepted. What we really need to do is revert the original situation to avoid a) uwsgi breaking glance and b) mod_wsgi dumping all uploads to temp 14:52:43 I think that was the crux of what we are battling with 14:53:21 rosmaita: didn't your patch take the route of mod_wsgi? 14:53:28 i'll have to look, i think my patch bypasses mod_wsgi 14:53:37 but honestly, it's been so long, i don't remember! 14:53:50 ok, cool ... then we just need to work with gmann to get that merged as agreed 14:54:07 but I guess some job is failing on that 14:54:08 yeah, lets double check that and start pushing it 14:54:26 ok 14:54:28 abhishekk: yes, grenade will so it will need so fiddlery to get in 14:54:49 yeah 14:55:27 but that's known issue we just need to work around and the process to do so is pretty well known so it should not be an issue 14:55:42 anything else burning ref S-1? 14:55:44 #link https://review.openstack.org/#/c/545483/4 14:55:53 that's the devstack fix 14:55:56 nothing at the moment 14:55:59 thnx rosmaita 14:56:18 last 5 minutes, I need your inputs on https://review.openstack.org/#/c/608856/ 14:56:30 #topic open discussion 14:56:35 this is the ML http://lists.openstack.org/pipermail/openstack-dev/2018-October/135402.html 14:57:33 In short for web-download functional tests we are downloading image which fails most of the time due to connectivity issues on the gate environment 14:57:39 looks like a good solution at first glance 14:58:02 So doug has suggested something like this 14:58:28 it will be great if that fixes the functional test problems 14:58:48 yeah, I will put some more efforts on this 14:59:31 Only problem is locally everything works, and I need to wait 3 hours to get results from gate 14:59:58 before you do, lets ping infra. I'm pretty sure there is http server running inside the gating environment we can put the tests running against instead of spinning up our own 15:00:41 I will ping you guys on glance channel if I encounter certain problems 15:00:50 sounds good 15:01:23 jokke_, only problem with that is if that httpd server is running on random port then we can not use that, as overriding config is not working in glance functional tests 15:02:04 and we have default [80, 443] in allowed_ports option, it will raise bad request for other ports 15:02:51 abhishekk: oh, there's that, gr8. Yet I'm pretty sure we can direct those tests to say, the pypi mirror gate is running. If there is no connection to that, the tests have failed already 15:03:19 as the gating VM has not been able to install 15:03:33 jokke_, let me check on that 15:03:40 that's it from me 15:04:00 just need to check with infra if it's ok to poke that server or if they have something else static we could use 15:04:10 ok, we're out of time. Thanks everyone 15:04:13 #endmeeting