14:01:53 #startmeeting glance 14:01:53 Meeting started Thu Oct 15 14:01:53 2020 UTC and is due to finish in 60 minutes. The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:58 The meeting name has been set to 'glance' 14:02:04 #topic roll call 14:02:06 o/ 14:02:07 o/ 14:02:08 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:02:15 o/ 14:02:26 hello every one 14:02:31 short agenda today :D 14:02:38 o/ 14:02:55 Lets start 14:03:14 #topic Updates 14:03:44 Next week is summit and PTG is in following week 14:04:14 Glance is scheduled between Tuesday to Friday around 1400 UTC to 1700 UTC 14:04:28 #link https://etherpad.opendev.org/p/Glance-Wallaby-PTG-planning 14:04:37 This is the planning etherpad 14:05:08 If you have anything in mind for discussion kindly add that in above etherpad 14:05:28 Also those who haven't registered yet, please register as well 14:06:10 Moving ahead 14:06:20 do you want to schedule line 98 along with cinder team as cross-project topic? 14:06:21 #topic release/periodic jobs update 14:06:42 rosmaita, that will be better 14:07:03 we can keep it on Friday or as per cinder team's availability 14:07:03 abhishekk: is wednesday good for that? 14:07:10 sounds good 14:07:27 Let me know the time slot as well 14:08:13 ok, will leave a note on the etherpad 14:08:29 cool, thank you 14:08:48 moving ahead 14:08:54 Victoria is released \o/ 14:09:06 Thank you all for your efforts and contribution 14:09:33 \\o \o/ o// o/7 14:09:42 \o/ 14:10:07 W is ahead of us, and during PTG we will finalize the priorities for W cycle 14:10:48 Periodic jobs are also green \o/ 14:11:10 moving ahead 14:11:32 #topic Meetings next 2 weeks 14:11:58 As next two weeks will be busy in summit and PTG, should we have meeting next week? 14:12:10 or Should we cancel for both weeks 14:12:48 I think we should cancel as usual. we'll be staying in touch a lot specially during ptg 14:12:56 +1 14:13:08 rosmaita, dansmith ? 14:13:12 yep, cancel 14:13:35 cool, I will send out info on openstack-discuss ML about cancellation 14:13:44 i am obviously not paying attention 14:13:50 cancel works for me, too 14:13:50 :D 14:13:54 ack 14:14:00 Lets move to Open discussion 14:14:09 #topic Open discussion 14:14:14 Anything? 14:14:24 I have something random, if there's nothing else 14:14:47 floor is yours 14:15:18 dansmith: congratulations on your TC election, by the way 14:15:38 indeed! Thanks ofr taking it on and GZ dansmith 14:15:40 jokke: thank you for running, hope you do it again next time 14:15:43 I'm sure this topic has come up before, but... especially for edge scenarios, there are situations where it would be really nice if an image had, uh, two formats, or a way to say "yeah I want that image, but in qcow2 format" 14:16:01 rosmaita: jokke I think you mean "condolences" but.. yeah thanks :) 14:16:17 Congratulations dansmith 14:16:27 I can think about a couple ways to do this, but wondering how much it has been discussed before? 14:16:30 dansmith: there used to be this thing called glare that did that 14:16:42 dansmith: thanks anyways :P 14:17:11 rosmaita: I know a few things about glare, but I wouldn't have included this.. did glare just maintain some relationships or did it do more? 14:17:12 dansmith: the traditional answer is that images are supposed to be immutable, that a motivated operator can connect different formatted payloads via metadata 14:17:13 that was way back, may be couple of years back 14:17:46 I was wondering if that was a glare thing. 14:18:28 I haven't heard much feedback from the edge WG, but it would be interesting to hear if they've come across any image management things like this that we need to start considering. 14:18:47 smcginnis: I seriously doubt the edge wg has discussed anything this technical :) 14:18:50 what rosmaita just said ... basically we have no problem "locking" thoe metadata keys down so it will be common across the intallations, but It's really metadata management issue 14:18:57 smcginnis: I'm talking about from our own edge team and customers 14:18:58 Haha, yep. 14:19:05 something I think Searhlight was also addressing with metadefs 14:19:45 jokke: right, so some standardized way of using metadata keys to indicate alternate formats would be one way, 14:19:47 smcginnis: they operate in much higher level than that 14:19:57 in such a way that nova could rely on it and use it to pick a different format 14:20:48 dansmith: our problem with this in the past has been having a definite well-defined use case 14:20:57 so it sounds like maybe you have one now 14:21:01 rosmaita: okay, do you want to hear my use-case? 14:21:15 yes, or at the ptg 14:21:17 we can also discuss this during the ptg if people would prefer, but 14:21:28 PTG will be good one to discuss 14:21:37 ...alright then :) 14:21:38 abhishekk: shall I add to the etherpad? 14:21:52 abhishekk: cinder is ending at 1600, so if you schedule this to start at 1600, that would be good 14:21:55 also, if you can put up a specs or lite-spec that will be good 14:22:01 (i think you said you are meeting 1400-1700 ?) 14:22:09 dansmith, yes, please add it to etherpad 14:22:10 dansmith: just throw your mind out so we have an idea what's coming. I think I know what you're after, but it doesn't hurt to have it out there in public 14:22:13 rosmaita, right 14:22:54 (i will stop paying attention again for a while_) 14:23:24 jokke: I don't really have anything baked, but some way of saying "the master image is $uuid, in raw format, but it has metadata entries for a qcow version (which is actually $uuid2) and a vmdk (which is $uuid3), so if you want those, actually go grab those instead 14:24:02 jokke: and then naturally it'd be nice to have a way to make glance generate those versions automatically after you've uploaded the raw, but that's not necessarily a requirement 14:24:19 jokke: but then nova can, if configured to prefer a qcow, grab the qcow variant instead 14:24:35 would probably be better if glance did it, to make sure the metadata is populated correctly 14:24:43 if it's doing the conversion, i mean 14:24:46 I can explain why this is important and what hacks we're doing now to avoid the wrong format at the ptg 14:24:55 rosmaita: yeah, I'd really like it if it could 14:25:15 rosmaita: because I also secretly think that would be better than image conversion on upload, but.. :) 14:25:28 (replacing image conversion isn't the goal here though) 14:26:01 anyway, 14:26:06 I think the biggest issue is how we communicate this to the user (Unless Nova uses the original ImageID in the instance metadata regardless which one it picked to be put down to disk) 14:26:25 jokke: yep, we'd have to figure that out for sure 14:26:47 jokke: but I think you're right, we'd need to use the original image uuid everywhere except the download, which would be fine, but there're still details with that approach 14:27:46 As if user sends request like "openstack virtual machine please boot me an instance form image with 300gig of cinder storage on flavor LAMPStack" and the instance has some other image ID when it comes up 14:28:19 yup that would be bad and stuff :) 14:28:36 the other way would be to tag a location with a format, so it's all one image 14:29:01 none of the hashing and verification supports that 14:29:02 I think that's likely to be more work, and it affects the API, but it would be more integrated 14:29:08 thta would need refactorng a lot 14:29:28 yes 14:29:53 yeah, so I think the "right" thing, if this was a feature from the beginning, would be that approach, but at this point it's too big a deal I suspect 14:30:32 I think it's one of those things that needs to be taken into consideration when designing Images API v3 ;P 14:33:55 as we don't do microversion, so we can't break the api nilly willy when ever we feel like so :P 14:34:13 anyway both the ways needs lots of work 14:35:07 abhishekk: establishing metadata relations between two images is not that big of a deal 14:35:08 abhishekk: the metadata way can be very little work, or more.. but anyway, let's discuss in the PTG 14:35:17 ++ 14:35:48 sounds good 14:37:10 dansmith, also let us know your convenient time for this discussion (kindly keep it post 1600 UTC) 14:37:38 abhishekk: meaning timezone-wise or conflicts with other groups? 14:37:52 timezone-wise, any time after 1400 is fine 14:38:13 dansmith, rosmaita will be busy with cinder between 1400 to 1600 UTC 14:38:23 ah okay 14:38:38 I have' 14:38:48 not even looked at the nova scheduling yet 14:38:53 :D 14:39:38 anything else? 14:39:42 jokke, rosmaita 14:39:51 nothing from me 14:40:25 nothing from me 14:40:25 cool, lets meet during PTG then 14:40:34 thank you all 14:40:45 have a great weekend and summit 14:40:46 thanks all 14:40:58 Long weekend for us Red Hatters 14:40:58 #endmeeting