Thursday, 2021-06-24

*** rpittau|afk is now known as rpittau07:21
abhishekk#startmeeting glance14:00
opendevmeetMeeting started Thu Jun 24 14:00:03 2021 UTC and is due to finish in 60 minutes.  The chair is abhishekk. Information about MeetBot at
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'glance'14:00
abhishekk#topic roll call14:00
abhishekklets wait couple of minutes more for others14:00
abhishekkcool lets start14:00
abhishekk#topic release/periodic jobs update14:00
abhishekkM2 3 weeks from now14:01
abhishekkWhich also means our spec freeze date is also approaching 14:01
abhishekkI would like all cores and members to go through policy refctoring spec as soon as possible14:01
abhishekkI would like to get it approved before next meeting 14:02
abhishekkPeriodic jobs, all green again14:02
abhishekkMoving ahead, 14:02
abhishekk#topic M2 Target progress check14:03
abhishekkFor quotas implementation, documentation, tempest work is complete for long now14:03
abhishekkWe need REVIEWS on top priority14:03
abhishekkTo achieve its due date and get it done before M214:03
abhishekkSo once again requesting voluntary core members and all members to spend some time on reviews as well14:04
abhishekkFor cache API there is one suggestion for Delete all call14:05
abhishekkat the moment we proposed to delete entire cache + queued images for delete all call14:05
abhishekkSo we would like to provide one flag which will tell to delete cached images only and keep queued list as it is14:06
abhishekkIn legacy tool we had separate calls for these two operations which we are merging into one in this proposal14:06
abhishekkSo any objection over this suggestion?14:06
dansmithsounds better to be able to evict or expire one thing and not the whole cache, especially given the size14:07
jokke_Or more like a scope where the requestor would be able to clear the current cache or the queue separately instead of just hitting them both14:07
jokke_dansmith: so individual control exists in the current proposal already14:07
dansmithoh I just re-read,14:07
dansmiththe separation is between the queue and currently-cached, I got it14:08
jokke_on image basis, but the clear all whacks both14:08
dansmithyep, sorry14:08
jokke_so if oyur automation went crazy and queued 100 images, you could clear that queue without affecting current cache14:08
dansmithfor sure14:08
abhishekkcool, as our proposal is already merged, how we can go for this14:09
jokke_or wise versa, you could just whack the current cache if you know they are not in use anymore to speed up the queue processing14:09
abhishekk1. submit different spec (lite) for this change14:09
abhishekk2. amend the original spec14:09
abhishekk3. Cover it in documentation14:09
jokke_As this is pretty simple adding a header to the delete call, do you guys feel we need to amend the spec or is this something we can consider implementation detail and handle on the code review?14:10
abhishekkOk, I will decide on approach later, lets move ahead14:11
dansmithjust amend the spec after you get the implementation done, IMHO14:11
jokke_I'm fine with that14:11
abhishekkHopefully by next week we will have patches up for reviews14:12
abhishekk#topic Image Encryption spec lite14:12
abhishekkIs Luzi around?14:12
abhishekkdo you have any specific questions?14:14
Luzii had a question specific to dansmith - in the spec-lite you mentioned this might be worth a full spec14:14
Luzii want to understand why? the WIP-patch builds up on a full spec with secret Consumers14:14
dansmithyeah, IMHO this has a lot of API impact and user behavior stuff in it, which I think is worth defining in more detail14:14
dansmithyeah, the original spec just says "meh, we'll figure this out later" for this part right?14:15
dansmithspecifically around the consumer bits14:15
dansmiththe original spec is for image encryption in general, and has lots of detail, but it just assumes the consumer stuff will be done14:16
Luziexactly - because the secret consumer API is still under work.14:16
dansmithright, but the impact to glance's API is pretty substantial,14:17
jokke_dansmith: how?14:17
rosmaitayeah, i don't see that either14:17
dansmithbecause you're talking about promising something to the users which you can't provide today, but  may in the future.. that'll be a behavioral change that you can't insulate them from14:17
rosmaitano, all we're promising is that if they have keys available, we will use them14:17
rosmaitabut key management is up to them14:17
dansmithbecause the implication, according to the original spec, is that when you've created an image based on the key, that you've grabbed a refcount on that key14:18
Luziso glance will only deal with two things: registering a secret consumer when creating an image and unregistering when it is deleted.14:18
dansmith"Glance register as a consumer of that14:18
dansmithkey (secret in Barbican [1]) when the corresponding encrypted image is14:18
dansmithuploaded and unregister as a consumer when the image is deleted in Glance."14:18
dansmithfrom the spec ^14:18
rosmaitai don't know that the consumer API is keeping an actual refcount14:18
dansmithbut what the lite spec is describing is just making that silently fail14:18
dansmithrosmaita: it's keeping a list of consumers, right? I'm just shortening that to refcount because that's the goal of it, IMHO14:19
jokke_dansmith: so what comes to the Glance side, is that we store the information and have dedicated property keys for them. Yes we do have in the full spec stating that we expect the consumer ap being present for this so we can register as consumer, and drop our registration, but glance is not doing the encryption nor the key management for those encrypted images, so I fail to see how this affects 14:19
jokke_our API14:19
rosmaitadansmith: yeah, whether its an actual refcount is not relevant, i was just wondering14:20
dansmithjokke_: because the spec says that we will have registered as a consumer of the key, which is the right behavior.. if we don't do that, and just return the image anyway, the user thinks they've got a hold of the key when they don't14:20
Luzidansmith, it is all up to the user. The secret consumers are just a help for users so a "secret delete" will not succeed as long as there are consumers (you should be able to force it though)14:20
dansmithjokke_: so my suggestion was to provide an intent flag during creation of an image with a key, saying "I really care that you secured a reference as a consumer on the key" or "I don't really care"14:21
abhishekkdansmith, are you worrying about accidental deletion of key by user?14:21
Luziwait - lets start with the workflow here14:21
dansmithtoday we can honor the latter, but can't honor the former14:21
dansmithbut after the consumer api is done, we can enable the former, and keep the same api semantics14:21
jokke_That said, like with lot of other our new features, I think would make lot of sense clearly mark this feature as EXPERIMENTAL until the secret consumer side is worked out and not claim it stable without14:21
dansmithotherwise people have to know what version of glance is on the backend in order to know if it should work ornot14:21
dansmithLuzi: yes, as I've said, I understand that it's just informational to the user, but it's a thing they are expecting to have to avoid losing data by deleting a key that is still in use14:22
dansmithjokke_: well, leaving it experimental is certainly better than nothing, I'd just rather make it very explicit14:23
jokke_dansmith: while I see your point and somewhat agree with it, As I understood the point with this lite-spec was to get the implementation parts moving while waiting for barbican (that we have done for over year now)14:24
abhishekkI guess our intention behind allowing this place holding to get things moving14:24
Luzidansmith, i would really like to have the secret consumers ready now. but the barbican team is drowning in other work as it seems and they are at a point where i cannot help them.14:24
dansmithjokke_: yep, and all I'm saying is that if we make the API intent more explicit, we're totally good to do that :)14:24
jokke_To have the bits in place to actually iron the rest out meanwhile. And experimental would be the approach for that14:24
dansmithPOST /v2/images?consumer=required  and POST /v2/images?consumer=optional14:25
dansmiththe former would always be 409 today, the latter would be 200, and we can go straight to supported for this API14:26
jokke_dansmith: with the intent flag on the API call, the problem is that we're stuck with it in the API ... ok, if it's experimental we in theory could drop it before making the API stable, but I'd rather avoid doing backwards incompatible changes to the API 14:26
dansmiththe users today have to declare "I understand that I may not have a refcount on my key"14:26
dansmithjokke_: well, it always makes sense to say "I don't care about the accounting" so it's not really something we're stuck with, it's just something we get14:27
dansmithjokke_: in fact, you could s/optional/ignore/ and then we could avoid the trip to barbican anyway, even once it's supported, if the user doesn't care14:27
dansmithbut see, all I said was "I think we might want to discuss this in a real spec" ... for this reason :D14:28
jokke_IMO that ^^ is the worst option around and will confuse shit out of everyone :D14:28
Luzii don't think we should support a mix between being able to add a secret consumer and just not do it...14:29
dansmithwhich? the spec or ignore?14:29
jokke_dansmith: ignore14:29
jokke_sorry, I was fixing my typos while you posted the spec comment14:29
Luzistill this is confusing to me - as i am the one writing things since years now...14:30
Luziwe have an original spec with the secret consumers14:30
rosmaitathe other thing is, isn't it possible for a user to upload the image data, and then add the metadata later? or are we disallowing that somehow?14:30
abhishekkI don't think we allow it14:31
dansmiththey have to be write-once14:31
dansmithotherwise people will try to re-encrypt their images with a new key right? :)14:31
Luziif you want to upload an encrypted image some sort of metadata is needed14:31
Luzire-encrypting would be a whole new issue14:31
Luziwell but whats different to the current situation in cinder for example14:32
jokke_I agree with the write once and the key metadata should be present when the container type is encrypted before the image goes active14:32
Luziyou can go to barbican and wildly delete random keys... or is there any way to prevent this?14:33
dansmiththe whole point of the consumer thing, is to at least *inform* the user that deleting a key will orphan real data14:33
dansmiththey should still be able to do it, of course, but the accounting is seriously important14:33
dansmithalso for auditing.. knowing which images or volumes or whatever are all encrypted with the same key is what keeps auditors up at night14:34
jokke_Luzi: the point was that we should protect the glance metadata. If you go and delete those keys from barbican, the image is useless after, just delete it and re-create with up-to-date metadata14:34
dansmithand making it easy to create a thousand images where all the accounting silently failed is problematic14:34
jokke_Luzi: but we do have mechanism for that already, so it's one of those implementation details that are pretty easy to enforce14:35
jokke_and imo not relevant for the intent of this light spec to just get the work moving while we wait for barbican14:35
Luzijokke_, with "you" I mean a user or project administrator14:35
Luzinot glance14:36
jokke_Luzi: correct, glance will never delete those keys14:36
abhishekkSo coming back to square 1, how much time it will take barbican to complete consumer work?14:36
rosmaitaok, i guess i agree with dan (assuming this is his point) ... we need to amend the original spec assuming that there is no secret consumer api and say precisely what the workflows are14:36
jokke_only once the consumer api is done letting brbican know that we refer to them14:36
dansmithrosmaita: that's not my point, but that would be better than nothing :)14:37
Luziabhishekk, i really have no idea - could be weeks or months... :/14:37
abhishekkLuzi ack14:37
jokke_Based on the fact that we have been waiting this for over a year and the last update I got was "maybe in this cycle" I'd not hold my breath with it14:38
Luziso instead of this lite spec you want me to edit the original spec - once for now without the secret consumers and once when we add them?14:38
abhishekkLuzi I think you can convert this lite spec to spec 14:39
dansmithis everyone else opposed to an intent flag? because that lets us out of this now and later when we get the consumer api14:39
dansmiththe default can be "optional" and nothing really has to change today14:39
abhishekkand mention the parent/former spec will be the feature work on top of this14:39
jokke_I'd prefer not. If we change the spec to state we are not using the consumer api that gives the expectation that we won't ... I'd rather really just start merging the bits Luzi need to keep the momentum going without expecting the secret consumer part is the first thing we depend on and not claim the work done before that's in place14:40
jokke_I thought that was the point of this lite-spec14:41
dansmithokay, and when the consumer api comes, we do what? convert to always using it *and* failing hard if we can't register?14:41
jokke_dansmith: correct14:41
jokke_as intended14:41
Luzidansmith, that would be the way 14:41
dansmithokay, as long as we don't squelch the failures (which is what the lite spec proposes) then I'm fine with that14:41
abhishekkLuzy hopefully your concern is addressed now14:43
Luziit's a bit more clear to me, what the problem is14:43
abhishekkLimited time, lets move ahead and circle back to it in open discussion if we have time left14:44
abhishekk#topic Policy refactoring14:44
abhishekkMaster spec:
abhishekkTests refactoring lite spec:
abhishekkAs I said we are approaching spec freeze and this time I want to honor it14:44
abhishekkKindly provide some time to review the spec14:44
abhishekkI have one +2 on the spec14:45
abhishekkrosmaita, jokke_ Steap_ smcginnis ^^^14:45
abhishekkAlso I would like to have one session about this work sometime in next two weeks 14:45
abhishekkso if anyone has any concerns then we can discuss it there only14:46
dansmithabhishekk: one session? meaning a voice call?14:46
abhishekkI will shoot one mail for the time slot and we could finalize the one14:47
abhishekkIf we fail to get it done this time then I guess it will never going to happen in future14:48
abhishekkthat's it from me for today14:48
abhishekkKindly put some time in reviews as well14:49
abhishekk#topic Open discussion14:49
abhishekkNothing from me14:49
dansmithplease review quota patches!14:50
* Steap_ is on his way to the reviewing room14:50
abhishekkI guess if that's it then we can wrap up and utilize remaining time in review14:51
abhishekkThank you all14:51
abhishekkHave a nice weekend ahead 14:51
opendevmeetMeeting ended Thu Jun 24 14:52:01 2021 UTC.  Information about MeetBot at . (v 0.1.4)14:52
opendevmeetMinutes (text):
jokke_thanks all14:52
*** rpittau is now known as rpittau|afk16:09

Generated by 2.17.2 by Marius Gedminas - find it at!