14:00:01 #startmeeting glance 14:00:02 Meeting started Thu Sep 27 14:00:01 2018 UTC and is due to finish in 60 minutes. The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:05 The meeting name has been set to 'glance' 14:00:14 #topic roll-call 14:00:21 o/ 14:00:24 o/ 14:01:22 o/ 14:01:27 o/ 14:03:12 o/ 14:03:30 #topic updates 14:05:00 First of all the periodic jobs: there was keystone tips failure, will need to keep eye on that and if it keeps failing see what is breaking it. Others are green 14:06:09 Based on the PTG we have quite a bit calmer cycle feature wise coming but reminder that the spec proposals will stay open until after Berlin Summit 14:07:46 I have yet to update the store driver maintainer page so will try to get that done by tomorrow eob 14:08:12 ack 14:08:36 I think that's pretty much it from quick updates from me 14:09:17 I did merge bunch of the zuul stuff that was sent in scripted 14:10:13 so if you think there was something that got messed up in the job definitions have a look and blame me :) 14:11:07 ack 14:11:19 #topic patch call to to replace locations 14:12:02 so we're back to imcdonns favorite child 14:12:58 which is also on my still to do list for this week. So I will have mail going to the ops list before next week checking if anyone else is using that API 14:13:27 ok 14:13:57 i don't see any reason why it makes sense for add /0 to have different behavior from replace {} 14:14:12 But in short, so there is couple of mistakes in Iain's statements to the dev mailing list 14:15:14 first, that after replacing the empty list there is nothing one can do to get the image out of queued, that's not trye, all the mechanisms that works before the replace call is made will still work after 14:15:27 so one doesn't just need to delete the image record 14:15:49 jokke_: what's the workaround? 14:17:05 rosmaita: so like it has always been patch call to add location does the status change, as does image upload and image import 14:18:04 but i mean in the situation where you just did the replace and are now in queued, what would you do? 14:18:08 and this is where me and Iain disagree ... I did agree on his initial statement that it's a bug that if you use the locations API there is _no_ way to activate the image as he stated when he came to us 14:18:57 ok, so the workaround is to add /0 in the first place 14:19:04 rosmaita: you do add and then you either delete or replace to get to single source of truth 14:19:24 rosmaita: no, that's the orginal idea how that API should work 14:19:41 you don't replace unless you're actually in need to replace something :) 14:20:34 I just thing no-one thought that one would want to start by replace and just built the whole final locations list by hand 14:20:38 sort of ... but it is legitimate to replace an empty list with a populated list 14:21:46 anyway, i didn't realize there was the workaround 14:21:57 (though i still think the replace situation is a bug!) 14:22:35 but the existence of a workaround does change the backport situation, i think 14:22:50 so my biggest problem with this is that we changed iirc deprecated API that has been stable for years based on bug that was filed on assumption "There is no way to do this at all" 14:24:16 well, i think a key thing is that we want consistent behavior in the api, and add /0 and replace {} should behave the same, i think 14:24:20 and yes if I was designing that API from scratch I definitely would take this use case in consideration and make sure the API behaves well, now the problem is really the API stability contract 14:26:23 i guess the key thing at this point is that we need a clear direction for how we will handle this. i understand both your and ian's frustration, but i personally don't know how to resolve this 14:27:37 but I'm kind of willing to let this slip in if there is no outcry us breaking someone else's process by us changing this. Is it valid bug for backporting within our stable rules, I don't think so but we can ask the rest of the stable folks after we make sure it's ok to keep in master 14:28:09 Sorry, I'm on the road and missed it. What's the stable change? 14:28:16 that is kind of where I'm at now 14:28:53 smcginnis: we're talking about the patch call replace locations to make image active 14:29:53 Ah, OK. Thanks! 14:33:06 And just that ye all are on the same page, I have no intention to make a rush call on this. We kind of need to make the call if we're reverting the patch on master by milestone 1 as at that point it will be in tagged release but what comes to backporting it into Rocky and perhaps before, I need to know that we're not on war path with everyone else to make one user able to use their preferred ap 14:33:12 i call instead of the one that just works 14:34:30 IMO we have been in enough wars for changing our stable APIs before ;) 14:35:19 speaking of which ... i take it you didn't like my proposal to make 'private' the default visibility? 14:36:13 rosmaita: actually we did ... IIRC that was what was originally agreed and the feedback has been it would make lots of users happier 14:37:00 oh wow, that's good to hear -- i may pick that up 14:37:13 i have like a 3 day window to do some glance work 14:37:21 :) 14:37:57 ok, if nothing else on this lets move on 14:38:04 great, then please review my patches 14:38:05 one thing 14:38:14 shoot 14:38:19 https://etherpad.openstack.org/p/glance-imacdonn-relnote 14:38:34 this was the description of the relnote for the replace change i wrote up 14:38:45 #link https://etherpad.openstack.org/p/glance-imacdonn-relnote 14:38:57 i think it may be slightly inaccurate 14:39:11 anyway, just pointing it out in case it will be helpful to advance the discussion 14:39:56 That looks good to me. 14:40:18 yeah, that's based on the original assumption that there is no way, in which case this change would have made sense 14:40:32 also, i speak of "adding" instead of "replace" 14:40:39 yup 14:40:47 +1 14:40:48 which is sort of the same thing, but inaccurate in this context 14:41:06 and the add already does behave like the reno proposal claims to change it to 14:41:16 ;) 14:41:30 i must admit, i misunderstood the situation 14:41:40 so did I initially 14:42:03 that's why I was like "Yes that does sound like nasty bug" 14:42:20 ok, in one sense we don't want to rush, but on the other, we do need to get it out of master pronto if we don't want to make this change 14:42:51 all i did was verify the bug, didn't think of trying a workaround 14:42:52 and then I started to look the code and wen't "WWaait!" and the discussion was left there when I went to PTO and meanwhile the change was merged ;) 14:44:13 rosmaita: like said I'm willing to let this slip if there is no outcry of us changing it from the API folks and operators. Because it does make sense in logical way 14:44:37 ++ 14:44:50 if it breaks anyone, I rather revert it and tell Iain "Sorry but you need to use the api call that already does it for you" 14:45:02 ok lets move on before we run out of time 14:45:18 #topic image encryption proposal 14:45:29 hello all :) 14:45:36 hi :) 14:45:40 hey! 14:45:42 we'd like to propose the introduction of an encrypted image format in OpenStack 14:45:51 we have written a spec for it and have a basic implementation ready which we'd like to contribute 14:46:05 based on the code alone Glance would be the least affected project (mostly Nova, Cinder and OSC are involved) 14:46:14 could you link the spec for us, please? 14:46:18 but we figured you are responsible for the image concept in OpenStack anyhow 14:46:34 so since the old cross-project contribution workflow is outdated, we're currently wondering where the best place to put the spec would be, actually 14:46:50 oh, Ok 14:47:34 any suggestions? 14:47:50 so that's a good question. I'd say you likely need to write 4 specs to all involved projects describing what you are trying solve and how it affects that project 14:48:10 and I don't mean 4 specs to each repo 14:48:31 but a spec to those 4 projects you need to change to make this happen 14:48:41 mhen: quick question, you mean a new value for the disk_format or container_format properties? 14:48:59 rosmaita, exactly, 'container_format' specifically 14:49:38 mhen: i wonder whether a new property would be better 14:49:43 Thinking from the Cinder side - I would expect the changes to not be too disruptive. So I think if you came to Cinder with changes saying they are for "the new encryption format from Glance" that we can probably just have a blueprint, not a full spec. 14:49:53 othewise, you might have encrypted_gzip, encrypted_raw, etc 14:49:56 I guess it really depends on the extent of the changes needed. 14:50:01 jokke_ but wouldn't it be better, if people from all involved project could discuss this in one repo? 14:50:27 I woud start with describing your goal with a ML post. 14:50:42 That woud be the best forum for cross-project discussion. 14:50:45 Luzi: yes I do agree, but like mhen said the cross project specs were sacked :( 14:51:00 what smcginnis just said, yes! 14:51:04 so we could use appropriate excerpts of the spec and post in on the ML? 14:51:16 *it 14:51:22 mhen: yes, that would be the best way to get started 14:51:43 that sounds reasonable, thanks for the suggestion! 14:52:01 mhen: just quick question as if you just were thinking of new container_format where are you planning to store the secrets? 14:52:06 I think so. Expain your use case(s), describe the changes you plan to make, and get input from affected projects. And have the opportunity for other interested parties to get involved too. 14:52:27 jokke_, key manager (e.g. Barbican) for now 14:52:52 we have other mechanisms in the work but they are currently not ready for contribution 14:53:06 mhen: ok, in that case you would likely want to have reserved property where to store that in glance as well 14:53:28 jokke_, that's what our implementation currently does basically 14:53:37 mhen: have you looked at how we handle the digital signatures? 14:53:53 we did, yes 14:53:58 ok, cool 14:54:01 one thing we have learned is that as glance has freeform properties for images, users really hates everyone using them as they wish ;) 14:54:11 we contributed image signature generation for OSC recently 14:54:53 nice 14:55:44 cool. Then I think the easiest for you guys get on this is like smcginnis proposed ML thread, get everyone on board and after that to file the specs or blueprints to affected projects 14:56:18 regarding the ML thing: iirc, there's a new combined ML coming up. It's still fine to post on the current openstack-dev? 14:56:43 for something like this we will want spec to glance-specs repo. It's even more for ducumenting the future change and book keeping than us just wanting to fight the design 14:56:43 Yes, no changes have been made yet, so posting to openstack-dev would be best. 14:56:55 * rosmaita has completely missed the discussion about a new ML 14:57:04 * jokke_ too 14:57:07 rosmaita: You've been busy. ;) 14:57:10 jokke_, we figured as much, that's why we came here first :) 14:57:20 mhen: gr8 14:58:11 ok, then we will do as you advised and post on the ML soon 14:58:41 mhen: just that you know. The image encryption has been discussed quite a bit and everyone has been kind of going away at the point when we have told them it's not Glance's job to encrypt those images but we're more than happy to keep track of it. By the looks of it you guys are taking the right approach ;) 14:59:23 I see. I can confirm that most code changes have to happen elsewhere, like I initally stated ;) 14:59:40 ;) 14:59:52 I look forward for the ML post 15:00:03 anything else you need from us now? 15:00:30 nope that would be sufficient for now, thanks for the talk! 15:00:42 well if so, we're out of time so lets continue if needed and Open discussion in #openstack-glance 15:00:46 thanks all! 15:00:58 #endmeeting