| opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Added context manager for instance lock https://review.opendev.org/c/openstack/nova/+/911394 | 06:14 |
|---|---|---|
| opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Separate OSError with ValueError https://review.opendev.org/c/openstack/nova/+/911395 | 06:14 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Disconnecting volume from the compute host https://review.opendev.org/c/openstack/nova/+/911396 | 06:14 |
| opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905135 | 06:24 |
| *** mklejn_ is now known as mklejn | 07:09 | |
| Uggla | bauzas, gibi, question are the test_migration tests running when we use the nova manage db sync command ? | 10:11 |
| bauzas | afaik nope | 10:12 |
| Uggla | bauzas, ok. | 10:16 |
| bauzas | ratailor__: I don't see a novaclient change for the 2.96 microversion | 10:52 |
| bauzas | are you planning to deliver it this cycle ? | 10:53 |
| bauzas | ratailor__: https://review.opendev.org/q/topic:%22list-requested-az%22 | 10:53 |
| bauzas | I +2d the sdk one and the osc one | 10:53 |
| bauzas | we shall at least bump https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py | 10:56 |
| bauzas | example of a noop client change https://github.com/openstack/python-novaclient/commit/85e4f08309490fa2ab6f0b581b3d645d2dbb5c4b | 10:56 |
| stblatzheim | sean-k-mooney, dansmith: I added you as reviewer for the next backport of cloud-init dhcp fix https://review.opendev.org/c/openstack/nova/+/911070 | 11:37 |
| ratailor | bauzas, ack. I will submit a patch for that adding noop client changes today. Thanks for reminding. | 12:14 |
| sean-k-mooney | stblatzheim: if i recall correctly you want to back port this one more time after that to zed correct | 12:30 |
| stblatzheim | correct | 12:32 |
| sean-k-mooney | cool | 12:33 |
| sean-k-mooney | im just capturing a comment for prosperity in the backport but its looks like a clean backport to me | 12:34 |
| sean-k-mooney | stblatzheim: ok +2 and i just noted what we chatted about yesterday in https://review.opendev.org/c/openstack/nova/+/911070/comments/17c649dc_46db2496 | 12:39 |
| opendevreview | Merged openstack/nova master: Implement add_consumer, remove_consumer KeyManager APIs https://review.opendev.org/c/openstack/nova/+/896100 | 12:53 |
| opendevreview | Rajesh Tailor proposed openstack/python-novaclient master: Bump microversion to 2.96 https://review.opendev.org/c/openstack/python-novaclient/+/911575 | 12:58 |
| ratailor | bauzas, for your reference https://review.opendev.org/c/openstack/python-novaclient/+/911575 | 13:06 |
| bauzas | ratailor: +2d | 13:07 |
| ratailor | bauzas, Thanks! | 13:07 |
| bauzas | sean-k-mooney: gibi: could you please look at https://review.opendev.org/c/openstack/python-novaclient/+/911575 ? | 13:07 |
| sean-k-mooney | am sure | 13:09 |
| stblatzheim | thank you sean-k-mooney :) | 13:23 |
| *** tosky_ is now known as tosky | 13:57 | |
| *** dansmith_ is now known as dansmith | 15:02 | |
| dansmith | melwitt: yeah so without the creator role (or whatever) in barbican, I can't boot.. and nova dumps a double-tall stack trace into the logs | 15:32 |
| dansmith | especially since that is likely to be a very common thing, surely we should catch and LOG.error that big mess instead right? | 15:33 |
| dansmith | it also seems like it's being handled as a "meh try it elsewhere" sort of thing because it hits NoHost, but this should, AFAICT, be a fatal do-not-retry sort of thing right? no reason to try it on three hosts when it will just fail everywhere | 15:33 |
| dansmith | from the outside, I don't think I can see anything about why this failed other than "not enough hosts" | 15:40 |
| dansmith | maybe we should have a "set up encryption" action event or something so we can see that's what actually failed? | 15:41 |
| opendevreview | Vlad Gusev proposed openstack/nova stable/zed: Unbind port when offloading a shelved instance https://review.opendev.org/c/openstack/nova/+/908694 | 15:50 |
| melwitt | dansmith: yeah, I agree that should be handled better. I'll put this on a list of changes to make. an instance action event is an interesting idea | 16:00 |
| dansmith | cool | 16:00 |
| *** clarkb1 is now known as clarkb | 16:55 | |
| melwitt | sean-k-mooney: this is how vtpm secrets get created, it's pretty similar https://github.com/openstack/nova/blob/master/nova/crypto.py#L171 | 16:57 |
| dansmith | melwitt: just to restate what I said with more context: | 17:24 |
| dansmith | I think the exception addition stuff should be as much before the create patch as possible because the create patch is already still bordering on overweight (like me) | 17:25 |
| dansmith | so adding fixes to previous stuff in there just makes it bigger | 17:25 |
| melwitt | dansmith: yeah, I agree that makes sense | 17:26 |
| sean-k-mooney | by the way the reason i was testing with admin demo beside the fact i was creating flavors was mainly because i tought tempst was testing with a normal user so i really was not expecting the creator role requirement | 17:27 |
| sean-k-mooney | i wont have time to test this again for likely a week or two but next time i test it ill try an swap beteen users betwen admin and non admin actions | 17:28 |
| melwitt | sean-k-mooney: this is the thing I was trying to say about the tempest roles https://github.com/openstack/barbican/blob/master/devstack/lib/tempest | 17:30 |
| melwitt | oh, interesting. the creator role requirement is a deprecated "legacy" policy https://github.com/openstack/barbican/blob/master/barbican/common/policies/secrets.py#L50 and the current policy only requires member. I'm checking why is it that devstack is defaulting to the deprecated "legacy" thing. I guess for compat with older stuff | 17:50 |
| melwitt | here's where it defaults to ENFORCE_SCOPE = False https://github.com/openstack/devstack/blob/5e837d1f0d9078c58bc634474a1adf311bc2b491/stackrc#L175 so if we set that to true before ./stack.sh then it would not require the creator role | 17:57 |
| melwitt | either way, we have to handle it gracefully but I didn't realize that the creator role thing was (thankfully) changed in the past | 17:58 |
| dansmith | yeah, definitely still want to handle it, but good if there's not going to be that hoop for admins to have to do | 18:02 |
| melwitt | ++ | 18:04 |
| sean-k-mooney | bauzas: i replied to your comment in https://review.opendev.org/c/openstack/nova/+/902687/4 by the way regarding the lock | 18:44 |
| dansmith | sean-k-mooney: melwitt confirmed with TPM: https://paste.openstack.org/show/bYK59AaAMr67tn9p56zP/ | 19:17 |
| sean-k-mooney | ack so that only works today because scope enforcement is disabled | 19:17 |
| sean-k-mooney | right | 19:17 |
| sean-k-mooney | well that or users need to have the creator role | 19:17 |
| melwitt | dansmith: ok, cool, thanks | 19:18 |
| sean-k-mooney | oh re reading melwitt comment | 19:18 |
| sean-k-mooney | so createor shoudl not be required now and member shoudl be enouch with new policy is that correct | 19:18 |
| melwitt | sean-k-mooney: yeah it's if scope enforcement is disabled, you need the creator role. if scope enforcement is enabled, you only need the member role | 19:18 |
| sean-k-mooney | ok so that also explains why this worked when we tested it with the new isntaller | 19:19 |
| sean-k-mooney | we are already enabeld the new SRBAC stuff there | 19:19 |
| melwitt | and scope enforcement is enabled by default. it's just in devstack it defaults to False | 19:19 |
| sean-k-mooney | ack | 19:19 |
| melwitt | ah, yeah | 19:19 |
| melwitt | yeah, I'll add these details to the spec too in regards to the role, like when it's needed | 19:20 |
| sean-k-mooney | cool gibi manually checked vtpm when we were adding barbican supprot. weill have automatic testing in the next few weeks | 19:20 |
| sean-k-mooney | but as i said we are using the new default and i dont know if he tested with admin but it worked there | 19:21 |
| sean-k-mooney | our downstrema docs for vtpm dont mention this as far as im aware but ill check quickly | 19:21 |
| sean-k-mooney | https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/17.1/html/configuring_the_compute_service_for_instance_creation/assembly_configuring-instance-security_vgpu#assembly_configuring-compute-nodes-to-provide-emulated-TPM-devices-for-instances_TPM | 19:22 |
| sean-k-mooney | ya so we dont which makes me think that creator has not been created for a while | 19:22 |
| sean-k-mooney | well that or there are two posiblities i guess tripleo deployed wallaby such that member was enouch | 19:23 |
| sean-k-mooney | or the same tempest change was copied into our jobs | 19:24 |
| sean-k-mooney | ah our job has the barbican plugin so we would not have seen it either way | 19:26 |
| sean-k-mooney | https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/.zuul.yaml#L114 | 19:26 |
| dansmith | not sure why you say that.. I'm just using the barbican plugin | 19:26 |
| sean-k-mooney | our whitebox test are using the default roles created for tempest | 19:27 |
| sean-k-mooney | dansmith: and as melwitt noted https://github.com/openstack/barbican/blob/master/devstack/lib/tempest#L9-L12 | 19:27 |
| sean-k-mooney | the tempest config tempest_roles key gets creator added | 19:27 |
| sean-k-mooney | https://github.com/openstack/tempest/blob/master/tempest/config.py#L64-L66 | 19:28 |
| sean-k-mooney | so all user created by tempest woudl hae the creator role | 19:28 |
| dansmith | oh you mean that's why or job works because it only needs the tempest users to have that permission, which it configures to happen | 19:28 |
| dansmith | yes | 19:28 |
| dansmith | sorry I thought you were asserting that because of the plugin we should be in the mode where it's not required | 19:29 |
| sean-k-mooney | ya so either we have the new defualts in 17.1 downstream or we have duplicated this tempst config in our downstream jobs | 19:29 |
| sean-k-mooney | my guess is 17.1 is configuring barbica so that member works | 19:30 |
| dansmith | yeah that I don' tknow | 19:30 |
| melwitt | sean-k-mooney: oh also the legacy barbican policy rule is "admin" or "creator". so if you have the admin role you don't need creator role | 19:35 |
| sean-k-mooney | it looks like the barbican user in the service ocnfigs has the creator roles https://github.com/openstack-archive/tripleo-heat-templates/blob/stable/wallaby/deployment/barbican/barbican-api-container-puppet.yaml#L259-L274 | 19:38 |
| sean-k-mooney | anyway with that in mind do we still want ot have a check for this in the api | 19:39 |
| sean-k-mooney | given we shoudl be using the new defaults in 2024.1 across all services | 19:39 |
| sean-k-mooney | looking at https://github.com/openstack/governance/blob/48d090643e7faf138b8f4e19f4a2915a20e1a873/goals/selected/consistent-and-secure-rbac.rst#20231-release-timeline | 19:41 |
| sean-k-mooney | barbica had supprot for enforce_new_defaults=True in antelope | 19:42 |
| sean-k-mooney | and in 2024.1 oslo is ment to remvoe enforce_scope | 19:42 |
| sean-k-mooney | https://github.com/openstack/governance/blob/48d090643e7faf138b8f4e19f4a2915a20e1a873/goals/selected/consistent-and-secure-rbac.rst#20241-release-timeline | 19:42 |
| sean-k-mooney | so as of this release and certenly for 2024.1 we shoudl be able to assume barbican has the behavior of enforce_scope=true | 19:43 |
| sean-k-mooney | *2024.2 | 19:46 |
| melwitt | sean-k-mooney: yeah.. I guess, I'm thinking of the upgrade scenario of a deployment that's been around for awhile and has enforce_scope = False set explicitly in policy? not sure how common that may be | 19:48 |
| sean-k-mooney | melwitt: it looks like oslo has not deprecate the option or change the default yet | 19:48 |
| sean-k-mooney | https://github.com/openstack/oslo.policy/blob/master/oslo_policy/opts.py#L27-L36 | 19:48 |
| JayF | I suspect it's reasonably common | 19:48 |
| melwitt | same.. | 19:48 |
| JayF | Ironic was configured that way (enforce_scope=False) by default until this cycle | 19:48 |
| sean-k-mooney | JayF: right so it looks like we did not make progress on changing the default and removing the option this cycle | 19:49 |
| melwitt | sean-k-mooney: yeah oslo_policy hasn't yet but barbican defaulting it https://github.com/openstack/barbican/blob/master/barbican/common/config.py#L357-L361 | 19:49 |
| sean-k-mooney | i remember this commign up in the last ptg | 19:49 |
| sean-k-mooney | melwitt: so we can do soemthing like this | 19:50 |
| sean-k-mooney | we can either use our new default value to infer barbicans | 19:51 |
| sean-k-mooney | and check for creator based on that or just catch the excption late | 19:51 |
| sean-k-mooney | once htis cant be turned off in barbican | 19:51 |
| sean-k-mooney | we can drop the check in nova | 19:51 |
| sean-k-mooney | and just rely on member | 19:51 |
| melwitt | I was gonna say that we could check [oslo_policy]enforce_scope and if it's False do the check to barbican API but that would be assuming barbican is deployed on the same host as nova-api. which may not be a safe assumption | 19:52 |
| sean-k-mooney | what that will actully mean is by default we wont need to check | 19:52 |
| sean-k-mooney | it might pass the api check when it shoudl not but we will catch the api error in the compute manager when we try to create a key | 19:53 |
| melwitt | er, or it would be assuming that barbican is configured the same. which it may not | 19:53 |
| sean-k-mooney | so its better then nothign for the small subset of pepole who diverge form the defaults | 19:53 |
| sean-k-mooney | right alghough you are not really ment to mix and match enfoce_scope | 19:54 |
| sean-k-mooney | i mean i guess it depends on how expensive the check is | 19:54 |
| sean-k-mooney | i dont know if oslo midelware gives us a list of all the roles on the token already | 19:55 |
| sean-k-mooney | if it does and its just a map lookup | 19:55 |
| sean-k-mooney | then it cheap and we can alwasy do it | 19:55 |
| sean-k-mooney | if its an api call to keystone on every spawn with this feature that when we might want to optimise | 19:55 |
| melwitt | I was thinking the same thing. I had been thinking it would have to be an api call but maybe we could do a lookup in the RequestContext or something | 19:57 |
| sean-k-mooney | ya im hoping that oslo.midelway or keystone auth is just giving use a list of roles when it doing the token validation in keystone and we can jsut check in that | 19:59 |
| gmann | sean-k-mooney: melwitt: we are not at the stage to remove/change defaults of enforce_scope in oslo.policy as many other project might be impacted but this config default can be overriden per service | 20:42 |
| gmann | for nova, it is enabled by default, this is where we override the default https://github.com/openstack/nova/blob/13ccaf75f61a19ba11f39b63052bcef5dfbce91f/nova/policy.py#L51 | 20:42 |
| sean-k-mooney | gmann: yep i know we have it enabled | 20:43 |
| gmann | We enabled them by default since Antelope release | 20:43 |
| sean-k-mooney | right but all project were ment to be enbaled by default last cycle | 20:44 |
| sean-k-mooney | i remember that we disucssed this last ptg | 20:44 |
| sean-k-mooney | and that they had not got tha tfar | 20:44 |
| sean-k-mooney | so i tought we were trying to do that for 2024.1 | 20:44 |
| gmann | it is still not there, I am picking one by one project. Tacker is my goal this cycle and will pick a few of them in next but progress from other projects is slow | 20:46 |
| sean-k-mooney | it might be better at this point to flip the default in olso and make project explcity opt out | 20:47 |
| gmann | yeah, I am also thinking that way. We can discuss it in PTG if no objection It think this is right way to proceed | 20:48 |
| sean-k-mooney | ack | 20:48 |
| gmann | sean-k-mooney: just in case you have not seen, this is updated version of testing runtime adding 3.12 in this doc as non-mandatory to test https://review.opendev.org/c/openstack/governance/+/908862 | 20:48 |
| sean-k-mooney | we coudl turn it on by default and deprecate it in oslo, and since its a non slurp we need to keep the option until at least 2025.2 | 20:49 |
| sean-k-mooney | gmann: thanks | 20:49 |
| gmann | I will say not to rush on remove as project adding scope in their policy will have it enabled by default. but other point is that we do not have system scope and it will be project scoped only so it does not break the things just improve the error msg if system scoped are used. | 20:51 |
| sean-k-mooney | gmann: https://review.opendev.org/c/openstack/governance/+/908862/6/reference/runtimes/2024.2.rst#61 minior nit but over all this looks fine to me | 20:51 |
| sean-k-mooney | gmann: well we cant basedon the slurp process | 20:51 |
| sean-k-mooney | gmann: oslo have not deprecated the options yet | 20:51 |
| gmann | yes | 20:51 |
| sean-k-mooney | so we cant remove until the deprecateion goes out in 2025.1 so 2025.2 woudl be the absolute earliest it coudl be removed now | 20:52 |
| gmann | yeah, we need it deprecated at least for 2025.1 | 20:52 |
| gmann | I will preapre the rbac PTG sessions etherpad to add this just in case we forget. I schedule session on Monday 13 UTC though | 20:53 |
| opendevreview | melanie witt proposed openstack/nova-specs master: Re-propose specs for ephemeral encryption https://review.opendev.org/c/openstack/nova-specs/+/907654 | 22:08 |
| *** kopecmartin_ is now known as kopecmartin | 22:50 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!