14:00:01 <jokke_> #startmeeting glance
14:00:02 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:05 <openstack> The meeting name has been set to 'glance'
14:00:14 <jokke_> #topic roll-call
14:00:21 <jokke_> o/
14:00:24 <Luzi> o/
14:01:22 <mhen> o/
14:01:27 <rosmaita> o/
14:03:12 <abhishekk> o/
14:03:30 <jokke_> #topic updates
14:05:00 <jokke_> 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 <jokke_> 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 <jokke_> I have yet to update the store driver maintainer page so will try to get that done by tomorrow eob
14:08:12 <abhishekk> ack
14:08:36 <jokke_> I think that's pretty much it from quick updates from me
14:09:17 <jokke_> I did merge bunch of the zuul stuff that was sent in scripted
14:10:13 <jokke_> so if you think there was something that got messed up in the job definitions have a look and blame me :)
14:11:07 <LiangFang> ack
14:11:19 <jokke_> #topic patch call to to replace locations
14:12:02 <jokke_> so we're back to imcdonns favorite child
14:12:58 <jokke_> 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 <abhishekk> ok
14:13:57 <rosmaita> i don't see any reason why it makes sense for add /0 to have different behavior from replace {}
14:14:12 <jokke_> But in short, so there is couple of mistakes in Iain's statements to the dev mailing list
14:15:14 <jokke_> 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 <jokke_> so one doesn't just need to delete the image record
14:15:49 <rosmaita> jokke_: what's the workaround?
14:17:05 <jokke_> 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 <rosmaita> but i mean in the situation where you just did the replace and are now in queued, what would you do?
14:18:08 <jokke_> 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 <rosmaita> ok, so the workaround is to add /0 in the first place
14:19:04 <jokke_> rosmaita: you do add and then you either delete or replace to get to single source of truth
14:19:24 <jokke_> rosmaita: no, that's the orginal idea how that API should work
14:19:41 <jokke_> you don't replace unless you're actually in need to replace something :)
14:20:34 <jokke_> 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 <rosmaita> sort of ... but it is legitimate to replace an empty list with a populated list
14:21:46 <rosmaita> anyway, i didn't realize there was the workaround
14:21:57 <rosmaita> (though i still think the replace situation is a bug!)
14:22:35 <rosmaita> but the existence of a workaround does change the backport situation, i think
14:22:50 <jokke_> 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 <rosmaita> 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 <jokke_> 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 <rosmaita> 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 <jokke_> 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 <smcginnis> Sorry, I'm on the road and missed it. What's the stable change?
14:28:16 <jokke_> that is kind of where I'm at now
14:28:53 <jokke_> smcginnis: we're talking about the patch call replace locations to make image active
14:29:53 <smcginnis> Ah, OK. Thanks!
14:33:06 <jokke_> 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 <jokke_> i call instead of the one that just works
14:34:30 <jokke_> IMO we have been in enough wars for changing our stable APIs before ;)
14:35:19 <rosmaita> speaking of which ... i take it you didn't like my proposal to make 'private' the default visibility?
14:36:13 <jokke_> 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 <rosmaita> oh wow, that's good to hear -- i may pick that up
14:37:13 <rosmaita> i have like a 3 day window to do some glance work
14:37:21 <jokke_> :)
14:37:57 <jokke_> ok, if nothing else on this lets move on
14:38:04 <abhishekk> great, then please review my patches
14:38:05 <rosmaita> one thing
14:38:14 <jokke_> shoot
14:38:19 <rosmaita> https://etherpad.openstack.org/p/glance-imacdonn-relnote
14:38:34 <rosmaita> this was the description of the relnote for the replace change i wrote up
14:38:45 <jokke_> #link https://etherpad.openstack.org/p/glance-imacdonn-relnote
14:38:57 <rosmaita> i think it may be slightly inaccurate
14:39:11 <rosmaita> anyway, just pointing it out in case it will be helpful to advance the discussion
14:39:56 <smcginnis> That looks good to me.
14:40:18 <jokke_> 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 <rosmaita> also, i speak of "adding" instead of "replace"
14:40:39 <jokke_> yup
14:40:47 <abhishekk> +1
14:40:48 <rosmaita> which is sort of the same thing, but inaccurate in this context
14:41:06 <jokke_> and the add already does behave like the reno proposal claims to change it to
14:41:16 <jokke_> ;)
14:41:30 <rosmaita> i must admit, i misunderstood the situation
14:41:40 <jokke_> so did I initially
14:42:03 <jokke_> that's why I was like "Yes that does sound like nasty bug"
14:42:20 <rosmaita> 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 <rosmaita> all i did was verify the bug, didn't think of trying a workaround
14:42:52 <jokke_> 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 <jokke_> 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 <rosmaita> ++
14:44:50 <jokke_> 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 <jokke_> ok lets move on before we run out of time
14:45:18 <jokke_> #topic image encryption proposal
14:45:29 <mhen> hello all :)
14:45:36 <Luzi> hi :)
14:45:40 <jokke_> hey!
14:45:42 <mhen> we'd like to propose the introduction of an encrypted image format in OpenStack
14:45:51 <mhen> we have written a spec for it and have a basic implementation ready which we'd like to contribute
14:46:05 <mhen> based on the code alone Glance would be the least affected project (mostly Nova, Cinder and OSC are involved)
14:46:14 <jokke_> could you link the spec for us, please?
14:46:18 <mhen> but we figured you are responsible for the image concept in OpenStack anyhow
14:46:34 <mhen> 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 <jokke_> oh, Ok
14:47:34 <mhen> any suggestions?
14:47:50 <jokke_> 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 <jokke_> and I don't mean 4 specs to each repo
14:48:31 <jokke_> but a spec to those 4 projects you need to change to make this happen
14:48:41 <rosmaita> mhen: quick question, you mean a new value for the disk_format or container_format properties?
14:48:59 <mhen> rosmaita, exactly, 'container_format' specifically
14:49:38 <rosmaita> mhen: i wonder whether a new property would be better
14:49:43 <smcginnis> 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 <rosmaita> othewise, you might have encrypted_gzip, encrypted_raw, etc
14:49:56 <smcginnis> I guess it really depends on the extent of the changes needed.
14:50:01 <Luzi> jokke_ but wouldn't it be better, if people from all involved project could discuss this in one repo?
14:50:27 <smcginnis> I woud start with describing your goal with a ML post.
14:50:42 <smcginnis> That woud be the best forum for cross-project discussion.
14:50:45 <jokke_> Luzi: yes I do agree, but like mhen said the cross project specs were sacked :(
14:51:00 <jokke_> what smcginnis just said, yes!
14:51:04 <mhen> so we could use appropriate excerpts of the spec and post in on the ML?
14:51:16 <mhen> *it
14:51:22 <rosmaita> mhen: yes, that would be the best way to get started
14:51:43 <mhen> that sounds reasonable, thanks for the suggestion!
14:52:01 <jokke_> 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 <smcginnis> 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 <mhen> jokke_, key manager (e.g. Barbican) for now
14:52:52 <mhen> we have other mechanisms in the work but they are currently not ready for contribution
14:53:06 <jokke_> mhen: ok, in that case you would likely want to have reserved property where to store that in glance as well
14:53:28 <mhen> jokke_, that's what our implementation currently does basically
14:53:37 <rosmaita> mhen: have you looked at how we handle the digital signatures?
14:53:53 <mhen> we did, yes
14:53:58 <rosmaita> ok, cool
14:54:01 <jokke_> 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 <mhen> we contributed image signature generation for OSC recently
14:54:53 <rosmaita> nice
14:55:44 <jokke_> 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 <mhen> 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 <jokke_> 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 <smcginnis> 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 <smcginnis> rosmaita: You've been busy. ;)
14:57:10 <mhen> jokke_, we figured as much, that's why we came here first :)
14:57:20 <jokke_> mhen: gr8
14:58:11 <mhen> ok, then we will do as you advised and post on the ML soon
14:58:41 <jokke_> 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 <mhen> I see. I can confirm that most code changes have to happen elsewhere, like I initally stated ;)
14:59:40 <jokke_> ;)
14:59:52 <jokke_> I look forward for the ML post
15:00:03 <jokke_> anything else you need from us now?
15:00:30 <mhen> nope that would be sufficient for now, thanks for the talk!
15:00:42 <jokke_> well if so, we're out of time so lets continue if needed and Open discussion in #openstack-glance
15:00:46 <jokke_> thanks all!
15:00:58 <jokke_> #endmeeting