Wednesday, 2021-03-03

*** whoami-rajat has quit IRC00:15
*** johanssone has quit IRC00:16
*** tosky has quit IRC00:17
*** johanssone has joined #openstack-glance00:19
*** felixhuettner[m] has quit IRC00:19
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: Implement API protection testing for images  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77356800:24
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: Add tests for image membership, deactivation, and reactivation  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77574200:24
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: WIP: Lay down system persona test plumbing  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77834300:24
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: Implement API protection testing for images  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77356800:26
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: Add tests for image membership, deactivation, and reactivation  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77574200:26
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: WIP: Lay down system persona test plumbing  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77834300:26
*** felixhuettner[m] has joined #openstack-glance00:28
dansmithlbragstad: just thought of something else..00:29
dansmither, wait, nevermind00:29
* dansmith needs to dinner00:30
lbragstadack00:30
openstackgerritLance Bragstad proposed openstack/glance master: Implement project personas for image actions  https://review.opendev.org/c/openstack/glance/+/76475400:31
openstackgerritLance Bragstad proposed openstack/glance master: Update default policies for task API  https://review.opendev.org/c/openstack/glance/+/76320800:31
openstackgerritLance Bragstad proposed openstack/glance master: Make secure RBAC protection job voting  https://review.opendev.org/c/openstack/glance/+/77825800:31
lbragstadok - that should take care of things? assuming the gtp tests still work and i didn't fat-finger something00:32
dansmithlbragstad: yeah, on your copy-image comment,00:35
dansmithit's fine to default to admin, but I can override to include regular members with what you have there right?00:35
dansmiththe comment is more "if we want the *default* to be different" or something right?00:35
dansmithokay I think the comment is about you using a simplistic check_str default,00:38
dansmithunlike the ADMIN_OR_PROJECT_MEMBER on most of the other rules00:38
dansmithalso commented on the set_image_location thing00:40
dansmithwill dig into that tomorrow.. didn't notice it before00:40
*** Underknowledge has quit IRC01:08
*** Underknowledge has joined #openstack-glance01:08
*** gyee has quit IRC01:17
openstackgerritDan Smith proposed openstack/glance master: Add housekeeping module and staging cleaner  https://review.opendev.org/c/openstack/glance/+/77701201:36
*** Underknowledge2 has joined #openstack-glance01:51
*** Underknowledge has quit IRC01:54
*** Underknowledge2 is now known as Underknowledge01:54
*** rcernin has quit IRC02:00
lbragstadyeah - you can override copy_image to be "" if you want and your nova job should still work02:14
lbragstadwith enforce_scope = True02:14
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: WIP: Lay down system persona test plumbing  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77834302:29
*** rcernin has joined #openstack-glance02:29
*** rcernin has quit IRC02:29
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: WIP: Lay down system persona test plumbing  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77834302:29
*** felixhuettner[m] has quit IRC02:29
*** rcernin has joined #openstack-glance02:30
*** felixhuettner[m] has joined #openstack-glance02:33
*** Underknowledge has quit IRC02:38
*** rcernin has quit IRC02:44
*** rcernin has joined #openstack-glance03:16
openstackgerritLance Bragstad proposed openstack/glance master: Implement project personas for image actions  https://review.opendev.org/c/openstack/glance/+/76475403:18
openstackgerritLance Bragstad proposed openstack/glance master: Update default policies for task API  https://review.opendev.org/c/openstack/glance/+/76320803:18
openstackgerritLance Bragstad proposed openstack/glance master: Make secure RBAC protection job voting  https://review.opendev.org/c/openstack/glance/+/77825803:18
*** dasp has quit IRC03:34
*** dasp has joined #openstack-glance03:45
*** k_mouza has joined #openstack-glance04:00
*** k_mouza has quit IRC04:05
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: Increase oslo.policy logging for protection tests  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77835604:14
*** zzzeek has quit IRC04:17
*** zzzeek has joined #openstack-glance04:17
*** zzzeek has quit IRC04:22
*** zzzeek has joined #openstack-glance04:23
*** udesale has joined #openstack-glance04:35
*** ratailor has joined #openstack-glance04:54
*** whoami-rajat has joined #openstack-glance04:58
*** ratailor_ has joined #openstack-glance05:26
*** ratailor has quit IRC05:29
*** ratailor__ has joined #openstack-glance05:34
*** m75abrams has joined #openstack-glance05:35
*** ratailor_ has quit IRC05:37
*** ajitha has joined #openstack-glance05:48
*** zzzeek has quit IRC06:06
*** zzzeek has joined #openstack-glance06:41
*** ralonsoh has joined #openstack-glance07:37
*** rcernin has quit IRC07:44
*** tosky has joined #openstack-glance08:34
*** jdillaman has quit IRC08:44
*** jdillaman has joined #openstack-glance08:45
*** Underknowledge has joined #openstack-glance09:11
openstackgerritMerged openstack/python-glanceclient master: Add Python3 wallaby unit tests  https://review.opendev.org/c/openstack/python-glanceclient/+/75070109:37
*** lpetrut has joined #openstack-glance10:22
*** k_mouza has joined #openstack-glance10:36
*** bhagyashris is now known as bhagyashris|rove11:30
*** bhagyashris|rove is now known as bhagyashri|rover11:30
*** udesale_ has joined #openstack-glance11:57
*** udesale has quit IRC12:00
*** legochen_ has joined #openstack-glance12:42
*** legochen_ is now known as legochen12:43
*** ratailor__ has quit IRC13:19
*** dirtwash has joined #openstack-glance13:40
dirtwashso I just setup a fresh ceph nautilus cluster with a fresh victoria openstanck and again snapshost fail, this is related to https://bugs.launchpad.net/glance/+bug/191648213:42
openstackLaunchpad bug 1916482 in Glance "rbd.IncompleteWriteError: RBD incomplete write (Wrote only 8388608 out of 8394566 bytes) since Victoria Upgrade, ceph v nautilus" [Undecided,New]13:42
dirtwashseems defo incompatiblity issue with Victoria glance release and ceph v14/nautilus13:42
jokkedirtwash: thanks, will try to look into the details today13:50
*** jv_ has quit IRC13:55
*** jv_ has joined #openstack-glance14:00
dirtwashkinda important because most big ceph users dont run latset stable (octoupus) because of early issues, all major clusters I know are still Nautilus, mine included14:07
*** takamatsu has joined #openstack-glance14:17
*** jdillaman has quit IRC14:18
*** jdillaman has joined #openstack-glance14:18
*** jv_ has quit IRC14:33
*** jv_ has joined #openstack-glance14:34
openstackgerritDan Smith proposed openstack/glance master: Add administrator docs for distributed-import  https://review.opendev.org/c/openstack/glance/+/77807214:38
openstackgerritDan Smith proposed openstack/glance master: Enable second glance worker for import testing  https://review.opendev.org/c/openstack/glance/+/77062914:38
*** jv_ has quit IRC14:59
*** jdillaman has quit IRC15:00
*** jv_ has joined #openstack-glance15:07
*** lpetrut has quit IRC15:09
*** happyhemant has joined #openstack-glance15:13
dansmithabhishekk: this is majorly cut down to just the important stuff and looks good to me: https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77356815:19
dansmithdo you think we're ready to go ahead and get that merged to help keep the number of pending patches down?15:19
jokkedansmith: you around?15:33
dansmithyup15:33
toskythere is a small cleanup (almost typo fix) you can merge before anything else: https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77356215:34
jokkedansmith: about the cleanup. Did you test that without moving the create pool out of the if clause? If I'm reading the code flow correctly in multi worker environment that pool gets actually never utilized and it would exists when called if it was still within the condition15:35
dansmithtosky: got it :)15:35
dansmithjokke: yeah, I moved it because of the way we start functional workers I think... move it back and run those and I think you'll see a NameError when we go to use self.pool15:36
dansmithjokke: if I'm mistaken, then I can move it back (although having instance variables sometimes missing is confusing anyway)15:36
dansmithI also really *really* don't think it's something we need to worry much about in terms of the overhead it may bring15:37
jokkedansmith: sure I'll give it a try. I thought each of the workers actually set their pool as self.pool as part of their spawn process. So the self.pool should be pointing to the last worker and then all the pools are in the async pool list15:37
jokkedansmith: true, just thinking we might be actually creating extra pool that gets never used unless workers == 015:38
dansmithI understand, I just don't think that's a huge deal.. if it pre-allocated a thousand threads then maybe, but .. :)15:39
jokkeyeah thankfully afaik the eventlet pools are not preallocating anything but the thread tracker. I think that's why we default like 1000 threads on them15:39
dansmithyeah15:41
abhishekkdansmith, So this https://review.opendev.org/c/openstack/glance-tempest-plugin/+/773568 is the patch which will verify that legacy rbac is working correctly and secure-rbac will fail until we adopt to new changes15:55
dansmithabhishekk: yep15:56
abhishekkcool15:56
abhishekkwill have a look soon enough15:57
openstackgerritDan Smith proposed openstack/glance master: Add housekeeping module and staging cleaner  https://review.opendev.org/c/openstack/glance/+/77701216:02
openstackgerritDan Smith proposed openstack/glance master: Add a check on startup for staging directory  https://review.opendev.org/c/openstack/glance/+/77849316:02
*** takamatsu has quit IRC16:11
*** smcginnis has quit IRC16:25
*** smcginnis has joined #openstack-glance16:34
*** m75abrams has quit IRC16:48
*** udesale_ has quit IRC16:52
*** jv_ has quit IRC17:01
*** ralonsoh has quit IRC17:01
*** hoonetorg has quit IRC17:01
*** stand has quit IRC17:01
*** lifeless_ has quit IRC17:01
dansmithlbragstad: I'm really struggling with these: https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77574217:01
dansmithI started by offering to comment them for you as I went through figuring them out, but ... I was stopped at like the second one17:01
*** openstackgerrit has quit IRC17:02
lbragstaddansmith ack - i'll take a look here soon17:03
dansmithack, sorry, I'm not very smart17:04
*** ralonsoh has joined #openstack-glance17:05
*** stand has joined #openstack-glance17:05
lbragstadi can understand the confusion - it's a lot to keep straight when you start dealing with multiple projects and clients17:05
dansmithyeah, it's more than I have fingers and toes :)17:06
*** jv_ has joined #openstack-glance17:07
*** hoonetorg has joined #openstack-glance17:07
*** lifeless_ has joined #openstack-glance17:07
abhishekkrosmaita, when you get time, please have a look at  https://review.opendev.org/c/openstack/glance/+/775860  and https://review.opendev.org/c/openstack/python-glanceclient/+/77640317:23
rosmaitaabhishekk: ack17:23
abhishekkboth are good to go and will reduce our M3 review list17:23
abhishekkthank you17:23
dansmithabhishekk: in order to test the cleanup of the conversion files in the functional test, I need to have them in the database17:46
dansmithabhishekk: is it okay to just use the existing uuids.stale as the base, and create several more files for it like .raw and .uc  and make sure those get hit?17:47
dansmithI can create another image for those too, but it'll just make that test longer17:47
abhishekkI think it will be ok to use uuids.stale as base17:47
dansmither, not uuids. stale, but the image I create/stage above17:47
dansmithokay, I think it's close enough too, just wanted to make sure17:48
abhishekkack17:48
dansmithactually, nevermind all that I'm being stupid17:49
dansmithnot a great day for me today :)17:50
abhishekk:D17:50
dansmithabhishekk: ^18:00
dansmither, where is the bot? :)18:00
abhishekkI think bot is also not having good day :D18:01
dansmithhaha18:01
abhishekkI got email update though, thank you18:01
dansmithcool18:01
abhishekkdansmith, could you please verify glance-store hash18:08
abhishekkhttps://review.opendev.org/c/openstack/releases/+/77797018:09
abhishekkI think it has +2 from zuul, but not merged yet18:09
dansmithabhishekk: done18:11
abhishekkthank you18:11
dansmithmaybe those are manual merges? it completed the gate18:13
abhishekkI think it will revisit gate once +w hits18:15
abhishekksmcginnis, ^^18:15
dansmithah, I see he dropped it, gotcha18:16
abhishekkme signing out for the day, will revisit rbac patches tomorrow18:17
dansmitho/18:17
abhishekko/~18:17
jokkenight18:18
*** ralonsoh has quit IRC18:23
jokkelbragstad: quick follow up about the community/public etc. all that.18:28
dansmithlbragstad: and while fixing whatever jokke just found, remove your non-voting job from the gate queue :) https://review.opendev.org/c/openstack/glance/+/77807918:29
* lbragstad nods18:30
lbragstaddansmith quick spot check18:30
dansmithI can ninja that patch when you fix18:31
jokkelbragstad: so yeah I saw your comment now on the add_image policy and how it kind of never hits in that specific case due to the other policy being on the way. Is it just perception thing (as in the string looks bad and like it could allow such) or is it as scary as it looks like and we need to be super careful?18:31
lbragstadhttps://review.opendev.org/c/openstack/glance-tempest-plugin/+/778538 is this the type of clarification you're asking for dansmith?18:32
lbragstadjokke well - it could be scary if something changes the order of operations as far as policy is concerned18:33
dansmithlbragstad: in general yeah, I'll go look, but... can't we have those comments in the patch where you're adding the tests to make it easier to review?18:33
lbragstador if glance decides to not nest policy enforcement checks18:33
lbragstaddansmith yeah - i'm planning on proposing that in the review you had comments on18:34
jokkelbragstad: so the policy actually works like I described in my comment and we're pretty much relying something else catching it first to avoid horrible things? :P18:34
lbragstadi just threw that up as a wip so you could easily see the different18:34
lbragstaddifference*18:34
dansmithlbragstad: ack cool18:34
lbragstadjokke well - yeah.. kind of18:36
lbragstadjust about every layer of glance wants at least *some* responsibility for authorization18:36
jokkelbragstad: for example my delete question below was very related for that exact reason. AFAIK there is no other policy to safeguard it18:36
lbragstadso - if we don't trip on the twig, we'll trip on the branch in the next step18:37
jokkelbragstad: I know :(18:37
lbragstadbut - i understand what you're saying18:37
lbragstadi think to address that18:37
jokkewe have loads of authorization that is 100% not relying the policies to check if action is ok or not.18:37
jokkewhich is sad18:38
lbragstadagreed - but.. i think the goal today should be18:38
lbragstadwrite a policy check string that encompasses the ideal use case18:38
lbragstadand make sure the behavior doesn't break18:38
*** lpetrut has joined #openstack-glance18:38
lbragstadthen we at least know the policy check isn't too restrictive18:39
lbragstadand as we sweep the authorization bits out of the database/authorization/controllers and into the policy layer18:39
lbragstadthe policy check string will naturally take on more authorization responsibility18:39
lbragstadand do what it's supposed to do18:39
lbragstadfor example18:39
lbragstadright now "get_image" has something like this for a check string18:40
lbragstad"role:admin or (role:reader and (project_id:%(project_id)s or project_id:%(member_id)s or "community":%(visibility)s or "public":%(visibility)s))"18:40
lbragstadbut the community and public parts of that check string aren't *fully* tested by the policy integration tests because that enforcement still lives in the database (from what I can understand and test)18:41
lbragstadbut - at least we have a check string that's relatively realistic and should hopefully act as a safeguard if/when we do start refactoring the database bits18:42
jokkelbragstad: also added clarification to https://accountantonline.ie/accountancy-fees/18:47
jokkesorry18:48
jokkehttps://review.opendev.org/c/openstack/glance/+/764754/23/glance/policies/image.py#30718:48
jokke^^ right link :D18:48
*** lpetrut has quit IRC18:49
lbragstadok - maybe i'm confused18:49
lbragstadi wasn't sure if we were talking about the add_image policy or the reactivate policy18:49
jokkelbragstad: ok that makes bit more sense in general. Not less scary looking 'though18:50
jokkelbragstad: oh I was going through your responses.18:50
lbragstadok - so end users are allowed to deactivate images, but only administrators can reactivate them?18:51
lbragstads/end users/project-members/18:51
jokkethe discussion here was mainly the impact of that check string, cause that looks in general scary AF. But lots of those thing you said makes more sense when you take the db restrictions and all that in to account18:51
jokkelbragstad: correct. as long as they are part of the owner tenant18:52
lbragstadso - if i decide to deactivate all images before i get fired, my manager has to contact the openstack operators to re-enable all of them after i've been escorted out?18:53
lbragstads/all images/all images in my project/18:53
* dansmith takes note18:53
jokkelbragstad: that's how it was designed ... which would explain why you got fired :P18:54
dansmithhah18:54
jokkeit's still less pain in the bollox than you deleting them which you would have permissions to do as well18:55
jokkeand would likely got you fired too18:55
lbragstadwell - i was probably fired for other reasons, but as a disgruntled employee i could hose images for my immediate project members and know it requires a ticket-based workflow somewhere18:55
dansmithyeah, it seems odd to me18:56
lbragstadjust playing devils advocate as someone really looking to stick it to the man before they get booted out the door :)18:58
jokkeIIRC the motivation for that was somewhere around these lines. Employee X finds weird behaviour on one of their images, deactivates it so no-one boots more instances from it before it's deemed safe. Now Employee Z who actually uploaded that malicious image, would obviously notice that his image got jammed so all he had to do was to either reactivate it or delete and recreate to play little more18:59
jokketime for it.18:59
jokkeSpecially if you use osc and rely image names that would be super effective19:00
lbragstadok - so that's assuming X and Z are both users within the same project19:00
lbragstadright?19:00
jokkeso the image literally gets locked before admin gives it a pass as default policy19:00
jokkelbragstad: yeah part of same tenant/project/<inject string what they are called today here>19:01
lbragstadenemy in the wire kind of thing?19:01
jokkemost of the time attacks comes from inside19:01
jokkealso admin could deactivate weirdly behaving image in their cloud instead of just deleting it for investigation19:02
lbragstadyeah - i think the admin case makes sense19:02
jokkeso it's really quarantine operation19:02
lbragstadi think it's certainly within their rights to activate and deactivate whatever they want19:02
lbragstadi guess i really wanted to understand the reason why project members didn't have the ability to reactivate images and require operator intervention19:04
dansmithjokke: is there any user doc material that describes it like that?19:04
jokkeI think it makes more sense maybe some day if we get these scopes little bit more in place. I could see reactivation being system or project admin etc.19:04
lbragstadmmm - exposing reactivate/deactivate to project-admins seems reasonable19:05
jokkelbragstad: it was really if anyone including operator did deactivate it, so the malicious user couldn't destroy the evidence and/or drop it back into use19:05
jokkedansmith: the original spec for example https://wiki.openstack.org/wiki/Glance-deactivate-image19:08
jokkedansmith: FAQ at the very end19:08
lbragstadso - from an operator perspective, of which i'm not ;)19:09
dansmiththis describes the opposite doesn't it?19:09
dansmithwhere a user can reactivate but an admin may only be able to deactivate?19:09
lbragstadif i notice someone is uploading malicious images within a paritcular project, i'm likely going to disable their entire project19:09
dansmithor have I been flipping this conversation? I thought you were saying a user could deactivate but then needs a ticket to reactivate19:10
jokkeI think this was the actual spec the implementation was based off https://specs.openstack.org/openstack/glance-specs/specs/kilo/deactivate-image.html19:10
lbragstad"If an image is deemed suspicious, an admin should be able to put the image “on hold” preventing instances from being built with it until it has be properly examined and determined to be safe or found dangerous and deleted. All image properties will remain accessible and editable, but the image will not be downloadable by non-admin users."19:11
lbragstadi think we have that part covered - yeah?19:11
jokkeno you're not. That original spec assumed the deactivate/reactivate was treated as single operation and described the problem exposing that flip state to the user19:12
jokkewhy it was later on split like proposed on that same statement to be behind two different policies so they can be controlled individually19:13
jokkelbragstad: I think it's one of those things where it's hardcoded to be admin operation only rather than utilixing policies to lock the data down when the image is deactivated19:14
lbragstadok - so we have a few options19:15
lbragstad1.) make deactivate/reactivate admin-only19:15
jokkeit was just the reactivation policy we should have admin by default as I think it has been so far19:15
lbragstad2.) expose deactivate to project-members and keep reactivate admin-only19:15
lbragstad3.) expose deactivate and reactivate to project-members19:16
dansmithjokke: was that "no you're not" aimed at my wondering about having this backwards?19:16
dansmithsounds like the current state is opposite from what that original spec proposed,19:16
jokkedansmith: yeah19:17
dansmithalthough  not sure if that changed along the way, or just in the implementation19:17
dansmithokay19:17
jokkedansmith: the original spec did present it backwards because it assumed it being single toggle opertion19:17
jokkeinstead of two different operations19:17
lbragstadi guess the case i'd like to avoid is #219:18
dansmithbut the original spec described admin having perms to deactivate, and user having activate... so still split now?19:18
dansmith*no19:18
jokkeit is still split and currently the default behaviour should be the option 2 lbragstad described19:18
lbragstadthat should be the default (#2)?19:19
dansmithokay, like lbragstad that seems not very useful to me, but it sounds like that makes it "like it is today" - for better or worse19:19
jokkeso as part of this work, I'd say lets keep it like that and if there is wish to change it, that should be it's own piece of work19:19
lbragstadas in that's how it *should* work today prior to any of the secure rbac changes?19:19
jokkecorrect ;)19:20
dansmithI'd like to know who is actually using this, and how...19:20
jokkedansmith: I've stumbled upon pretty creative use cases for the feature19:20
lbragstadumm19:20
lbragstadhttps://review.opendev.org/c/openstack/glance-tempest-plugin/+/775742/11/glance_tempest_plugin/tests/rbac/v2/test_images.py@143119:20
lbragstadthat ^ test passes with legacy rbac... as in no new project personas19:20
dansmithlbragstad: meaning a regular user can reactivate yeah?19:21
lbragstadhttps://1e03df7e49d16b52a381-065293745cdcc6ecb6052ade0199e5ba.ssl.cf2.rackcdn.com/775742/11/check/glance-legacy-rbac-protection-functional/fe5e8a6/testr_results.html19:21
lbragstadyes19:22
dansmithlbragstad: see why I wanted the tests to land first? :)19:22
dansmithlbragstad: we get a 204 there, I wonder if it's just not actually reactivated even though it told us it was?19:22
jokkehmm-m that's likely due to something that has slipped when we stopped shipping default policy file, as that was one of the rare default overwrites we did ship from the permissive policy19:23
jokkewhich would be super easy to check if we still had our policy files19:25
dansmithjokke: https://github.com/openstack/glance/blob/stable/stein/etc/policy.json#L3619:26
dansmithlooks unrestricted to me19:26
dansmithall the way back to ocata19:26
dansmith(unless I'm looking at the wrong thing)19:28
jokkeyup, looks like I did remember that wrong19:28
jokkenow I'm wondering how we are shipping that from OoO etc.19:28
dansmithso, maybe the default was the intent,19:28
dansmithbut the shipped policy didn't match19:28
dansmithwell, no the default was default for both right?19:29
dansmithheh, default was "rule:default" I mean19:29
dansmithwhich is "anyone that can see the image" ?19:29
jokkeyeah our default policy has been pretty permissive about everything for testing19:30
jokkelike many things that we document should be admin only or restricted, are in repo with empty string so we can test it19:30
dansmiththe tests override the policy to be unrestricted, AFAIK, so I don't think this file affects them that I know of19:31
jokkenowadays yes19:31
jokkeiirc even tempest used to be like default policies and tempest tests only user functions, if it needed admin credentials it was out of scope ofr tempest19:32
jokkebut indeed looks like this is yet another of those things that we've been shipping opposite what we expect in the docs :(19:33
dansmithwell, that's the point of the defaults-in-code work, so ... good? :)19:33
jokkewell no, now when it's hidden all over the place in code it's even mre difficult to chec vs. when it was one clean file ;)19:34
dansmithwell, disagree on that, but the point is to not be shipping two copies of things that can (and clearly do) get out of sync19:35
lbragstadwell - just because it was in the file doesn't mean what was in the file was true with what is in the rest of glance that does authorization stuff19:35
dansmithwell, that's a whole other thing19:36
jokkelbragstad: well the policies being in the code does not change the out of the policies auth either ;D19:36
lbragstadi think i understand that bit, but i don't think having a policy file necessarily makes this better19:37
lbragstadtheoretically - we would have hit these issues 4 or 8 cycles ago if we wrote the same tests then, no?19:38
jokkebut at least the new definitions under /glance/policies are much more undestandable than the old policy.json or the intermediate one we're moving away now19:38
jokkeI really liked the old file based policies. It was so clear and all package managers knew how to deal with/warn if there was changes coming from upstream on upgrade.19:41
lbragstadwe have deprecation signaling for that now19:41
lbragstadthe file-based approach didn't really give us a way to handle things gracefully for operators on upgrade19:42
dansmithyeah19:42
dansmithbut regardless, here we are, not much point in discussing that here and now19:43
jokkewell at least it won't change anytihng19:43
dansmithsounds like to be the most compatible, we should keep both operations open to everyone and maybe have a reno to alert operators if they for some reason find that surprising?19:44
lbragstadso approach #3?19:44
dansmithnot really sure it should be surprising to anyone, I guess, given all the defaults were open/open AFAICT19:44
dansmithyeah19:44
lbragstadok - so i don't think i need to update that specific policy in question then19:45
jokkedansmith: not _all_ :P19:45
jokke "publicize_image": "role:admin",19:45
jokke    "manage_image_cache": "role:admin",19:45
jokke    "tasks_api_access": "role:admin",19:45
dansmithwhere is that?19:46
jokkethat's from stable/train policy.json we shipped19:46
dansmithchanged in stable? but aren't we talking about (re)activate ?19:47
jokkeall the defaults19:47
dansmithhttps://github.com/openstack/glance/blob/stable/train/etc/policy.json#L3619:48
dansmithare you talking about downstream?19:48
jokkedansmith: all the defaults not that specific one ...19:48
jokkeI was pointing out that I managed to find 3 from the whole bloody thing that were not wide open :P19:49
dansmithoh,, I see.. I meant s/all/both/ above, in "all the places"19:49
jokke'though I'm not sure if that file has all possible policies mapped ... the default was admin, so anyhing not listed should be pointing to admin19:50
*** whoami-rajat has quit IRC19:50
jokkebut yeah, I don't think this is the right place to lock the specific one down lbragstad go with #3, sorry for confusion and derailing the convo for past 2 hours or so19:51
jokkemy comment was based on how it was supposed to be, not how it has been shipping19:52
lbragstadok - but we're good with exposing this at the project-level is what i'm hearing19:52
jokkewell t least we know it's policy controlled. Not that it gets blocked somewhere else due to being hardcoded19:54
*** lifeless_ is now known as lifeless19:56
lbragstadwell - kind of19:56
lbragstadhttps://opendev.org/openstack/glance/src/branch/master/glance/api/authorization.py#L369-L37119:57
lbragstad^ i have no idea how or where that gets invoked19:57
lbragstadit doesn't appear to be in the code paths i'm testing19:57
lbragstadbut that's the code equivalent of "!" deny all19:58
jokkeuuh, that's immutable proxy19:58
lbragstadi'm not sure if you have to do something special to hit that?19:58
jokkeyeah, that's literally read-only image object19:58
lbragstadah19:58
jokkeI think that might be the mecanism which prevets lots of things happening if you're not the owner19:59
lbragstadso - that could be something like "False:%(protected)s" if we were to convert that19:59
dansmithit's very effective, and also very frustrating from a testing perspective :)20:00
dansmithit's a very brute-force way to make sure you don't accidentally mutate anything in the image, like metadata or the many linked structures you get back with an image20:01
dansmiththere's magic that happens when you save an image, so it seems to aim to generate an exception when you even touch your "image" object before you get a chance to save() it and maybe have some unintended things get changed20:02
jokkedansmith: yeah20:02
jokkelike you said it's crude but effective20:02
lbragstadok - sounds like the publicize image policy check and how that's invoked before add_image20:03
dansmithyeah, I can see places where it would allow a leak, thinking that it was airtight, and also where it would prevent us from allowing certain operations we want to grant, without granting control over the image itself20:03
jokkeit's also very frustrating combo with the domain model and all possible proxies20:04
jokkewhere you really never know which object you actually got back. it might look right but only way to be sure is to check the type20:05
jokkespecially when there is stuff like properties which might be some proxy object depending where you got the image object from, and which layer happened to swap it between proxy object that behaves bit like a list or dict vs actual list or dict20:06
jokkewhich is what I assume was happening on that locations list you had to remove. It should be just list of dicts, but some layers gives you proxy20:07
jokkebut it's past 8PM. Dinner, movie or something and sleep.20:12
*** happyhemant has quit IRC20:13
lbragstadok - i'm following up on the whole 204/actual deactivation thing20:20
lbragstadthe status when a project-member deactivates an image is 'deactivate'20:21
dansmithlbragstad: don't leave us hanging bro20:46
lbragstadthat's it - that's the news20:46
*** rcernin has joined #openstack-glance20:46
dansmithI thought you were going to try reactivate as a user and see if it actually recovers20:46
lbragstadoh - yeah, i think we have a test for that20:48
*** k_mouza has quit IRC20:49
*** openstackgerrit has joined #openstack-glance20:49
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: Add tests for image membership, deactivation, and reactivation  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77574220:49
lbragstadok - i loaded ^ with a bunch of comments20:50
lbragstadto hopefully make the tests a little more clear20:50
*** gyee has joined #openstack-glance21:01
*** rcernin has quit IRC21:17
dansmithlbragstad: definitely helpful, and seems like your comment density went up as you got further in the file :)21:17
dansmithstill have some questions, which I just left in there21:17
dansmiththey're probably more like "glance will let you do whaa?" than actually policy-related, but.. since you're asserting that things are this way, you get to shoulder that burden I guess :)21:18
dansmithactually, nevermind, I should have just looked it up myself first21:27
*** irclogbot_0 has quit IRC21:33
*** ianw has quit IRC21:33
*** lyr has quit IRC21:33
*** freerunner has quit IRC21:33
*** irclogbot_0 has joined #openstack-glance21:34
*** ianw has joined #openstack-glance21:34
*** lyr has joined #openstack-glance21:34
*** freerunner has joined #openstack-glance21:34
*** zzzeek has quit IRC21:44
*** zzzeek has joined #openstack-glance21:45
*** rcernin has joined #openstack-glance22:05
*** rcernin has quit IRC22:11
*** rcernin has joined #openstack-glance22:11
*** ajitha has quit IRC22:23
openstackgerritDan Smith proposed openstack/glance master: Add housekeeping module and staging cleaner  https://review.opendev.org/c/openstack/glance/+/77701222:43
openstackgerritDan Smith proposed openstack/glance master: Add a check on startup for staging directory  https://review.opendev.org/c/openstack/glance/+/77849322:43
*** k_mouza has joined #openstack-glance22:49
*** k_mouza has quit IRC22:54
*** rcernin has quit IRC22:56
*** rcernin has joined #openstack-glance23:01
*** k_mouza has joined #openstack-glance23:17
openstackgerritDan Smith proposed openstack/glance master: Enable second glance worker for import testing  https://review.opendev.org/c/openstack/glance/+/77062923:18
*** k_mouza has quit IRC23:22
*** rcernin has quit IRC23:26
*** k_mouza has joined #openstack-glance23:27
*** k_mouza has quit IRC23:31
*** k_mouza has joined #openstack-glance23:36
openstackgerritLance Bragstad proposed openstack/glance-tempest-plugin master: Add tests for image membership, deactivation, and reactivation  https://review.opendev.org/c/openstack/glance-tempest-plugin/+/77574223:39
lbragstaddansmith ok - i pulled some of your subtext comments into ps1323:40
lbragstadbut i wasn't sure if you meant for some of those to be added or not?23:40
*** zzzeek has quit IRC23:40
lbragstadif i misinterpreted that - let me know and i can re-add them23:40
lbragstader - add them*23:40
*** k_mouza has quit IRC23:41
*** zzzeek has joined #openstack-glance23:42
openstackgerritLance Bragstad proposed openstack/glance master: Add glance functional protection tests to check and gate  https://review.opendev.org/c/openstack/glance/+/77807923:42
dansmithlbragstad: yeah, happy to have them in there23:46
dansmithlbragstad: ninja'd the test job patch23:47
lbragstadsweet23:47
openstackgerritMerged openstack/glance master: Distributed image import  https://review.opendev.org/c/openstack/glance/+/76997623:59

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!