Wednesday, 2024-03-06

opendevreviewAmit Uniyal proposed openstack/nova stable/2023.2: Added context manager for instance lock  https://review.opendev.org/c/openstack/nova/+/91139406:14
opendevreviewAmit Uniyal proposed openstack/nova stable/2023.2: Separate OSError with ValueError  https://review.opendev.org/c/openstack/nova/+/91139506:14
opendevreviewAmit Uniyal proposed openstack/nova stable/2023.2: Disconnecting volume from the compute host  https://review.opendev.org/c/openstack/nova/+/91139606:14
opendevreviewAmit Uniyal proposed openstack/nova stable/2023.2: Refactor vf profile for PCI device  https://review.opendev.org/c/openstack/nova/+/90513506:24
*** mklejn_ is now known as mklejn07:09
Ugglabauzas, gibi, question are the test_migration tests running when we use the nova manage db sync command ?10:11
bauzasafaik nope10:12
Ugglabauzas, ok.10:16
bauzasratailor__: I don't see a novaclient change for the 2.96 microversion10:52
bauzasare you planning to deliver it this cycle ?10:53
bauzasratailor__: https://review.opendev.org/q/topic:%22list-requested-az%2210:53
bauzasI +2d the sdk one and the osc one10:53
bauzaswe shall at least bump https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py10:56
bauzasexample of a noop client change https://github.com/openstack/python-novaclient/commit/85e4f08309490fa2ab6f0b581b3d645d2dbb5c4b10:56
stblatzheimsean-k-mooney, dansmith: I added you as reviewer for the next backport of cloud-init dhcp fix https://review.opendev.org/c/openstack/nova/+/91107011:37
ratailorbauzas, ack. I will submit a patch for that adding noop client changes today. Thanks for reminding. 12:14
sean-k-mooneystblatzheim: if i recall correctly you want to back port this one more time after that to zed correct12:30
stblatzheimcorrect12:32
sean-k-mooneycool 12:33
sean-k-mooneyim just capturing a comment for prosperity in the backport but its looks like a clean backport to me12:34
sean-k-mooneystblatzheim: ok +2 and i just noted what we chatted about yesterday in https://review.opendev.org/c/openstack/nova/+/911070/comments/17c649dc_46db249612:39
opendevreviewMerged openstack/nova master: Implement add_consumer, remove_consumer KeyManager APIs  https://review.opendev.org/c/openstack/nova/+/89610012:53
opendevreviewRajesh Tailor proposed openstack/python-novaclient master: Bump microversion to 2.96  https://review.opendev.org/c/openstack/python-novaclient/+/91157512:58
ratailorbauzas, for your reference https://review.opendev.org/c/openstack/python-novaclient/+/91157513:06
bauzasratailor: +2d13:07
ratailorbauzas, Thanks!13:07
bauzassean-k-mooney: gibi: could you please look at https://review.opendev.org/c/openstack/python-novaclient/+/911575 ?13:07
sean-k-mooneyam sure13:09
stblatzheimthank you sean-k-mooney :)13:23
*** tosky_ is now known as tosky13:57
*** dansmith_ is now known as dansmith15:02
dansmithmelwitt: yeah so without the creator role (or whatever) in barbican, I can't boot.. and nova dumps a double-tall stack trace into the logs15:32
dansmithespecially since that is likely to be a very common thing, surely we should catch and LOG.error that big mess instead right?15:33
dansmithit 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 everywhere15:33
dansmithfrom the outside, I don't think I can see anything about why this failed other than "not enough hosts"15:40
dansmithmaybe we should have a "set up encryption" action event or something so we can see that's what actually failed?15:41
opendevreviewVlad Gusev proposed openstack/nova stable/zed: Unbind port when offloading a shelved instance  https://review.opendev.org/c/openstack/nova/+/90869415:50
melwittdansmith: 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 idea16:00
dansmithcool16:00
*** clarkb1 is now known as clarkb16:55
melwittsean-k-mooney: this is how vtpm secrets get created, it's pretty similar https://github.com/openstack/nova/blob/master/nova/crypto.py#L17116:57
dansmithmelwitt: just to restate what I said with more context:17:24
dansmithI 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
dansmithso adding fixes to previous stuff in there just makes it bigger17:25
melwittdansmith: yeah, I agree that makes sense17:26
sean-k-mooneyby 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 requirement17:27
sean-k-mooneyi 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 actions17:28
melwittsean-k-mooney: this is the thing I was trying to say about the tempest roles https://github.com/openstack/barbican/blob/master/devstack/lib/tempest17:30
melwittoh, 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 stuff17:50
melwitthere'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 role17:57
melwitteither way, we have to handle it gracefully but I didn't realize that the creator role thing was (thankfully) changed in the past17:58
dansmithyeah, definitely still want to handle it, but good if there's not going to be that hoop for admins to have to do18:02
melwitt++18:04
sean-k-mooneybauzas: i replied to your comment in https://review.opendev.org/c/openstack/nova/+/902687/4 by the way regarding the lock18:44
dansmithsean-k-mooney: melwitt confirmed with TPM: https://paste.openstack.org/show/bYK59AaAMr67tn9p56zP/19:17
sean-k-mooneyack so that only works today because scope enforcement is disabled19:17
sean-k-mooneyright19:17
sean-k-mooneywell that or users need to have the creator role19:17
melwittdansmith: ok, cool, thanks19:18
sean-k-mooneyoh re reading melwitt comment19:18
sean-k-mooneyso createor shoudl not be required now and member shoudl be enouch with new policy is that correct19:18
melwittsean-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 role19:18
sean-k-mooneyok so that also explains why this worked when we tested it with the new isntaller19:19
sean-k-mooneywe are already enabeld the new SRBAC stuff there19:19
melwittand scope enforcement is enabled by default. it's just in devstack it defaults to False19:19
sean-k-mooneyack19:19
melwittah, yeah19:19
melwittyeah, I'll add these details to the spec too in regards to the role, like when it's needed19:20
sean-k-mooneycool gibi manually checked vtpm when we were adding barbican supprot. weill have automatic testing in the next few weeks 19:20
sean-k-mooneybut as i said we are using the new default and i dont know if he tested with admin but it worked there19:21
sean-k-mooneyour downstrema docs for vtpm dont mention this as far as im aware but ill check quickly19:21
sean-k-mooneyhttps://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_TPM19:22
sean-k-mooneyya so we dont which makes me think that creator has not been created for a while19:22
sean-k-mooneywell that or there are two posiblities i guess tripleo deployed wallaby such that member was enouch19:23
sean-k-mooneyor the same tempest change was copied into our jobs19:24
sean-k-mooneyah our job has the barbican plugin so we would not have seen it either way19:26
sean-k-mooneyhttps://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/.zuul.yaml#L11419:26
dansmithnot sure why you say that.. I'm just using the barbican plugin19:26
sean-k-mooneyour whitebox test are using the default roles created for tempest19:27
sean-k-mooneydansmith: and as melwitt noted https://github.com/openstack/barbican/blob/master/devstack/lib/tempest#L9-L1219:27
sean-k-mooneythe tempest config tempest_roles key gets creator added19:27
sean-k-mooneyhttps://github.com/openstack/tempest/blob/master/tempest/config.py#L64-L6619:28
sean-k-mooneyso all user created by tempest woudl hae the creator role19:28
dansmithoh you mean that's why or job works because it only needs the tempest users to have that permission, which it configures to happen19:28
dansmithyes19:28
dansmithsorry I thought you were asserting that because of the plugin we should be in the mode where it's not required19:29
sean-k-mooneyya so either we have the new defualts in 17.1 downstream or we have duplicated this tempst config in our downstream jobs19:29
sean-k-mooneymy guess is 17.1 is configuring barbica so that member works19:30
dansmithyeah that I don' tknow19:30
melwittsean-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 role19:35
sean-k-mooneyit 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-L27419:38
sean-k-mooneyanyway with that in mind do we still want ot have a check for this in the api19:39
sean-k-mooneygiven we shoudl be using the new defaults in 2024.1 across all services19:39
sean-k-mooneylooking at https://github.com/openstack/governance/blob/48d090643e7faf138b8f4e19f4a2915a20e1a873/goals/selected/consistent-and-secure-rbac.rst#20231-release-timeline19:41
sean-k-mooneybarbica had supprot for  enforce_new_defaults=True in antelope 19:42
sean-k-mooneyand in 2024.1 oslo is ment to remvoe enforce_scope19:42
sean-k-mooneyhttps://github.com/openstack/governance/blob/48d090643e7faf138b8f4e19f4a2915a20e1a873/goals/selected/consistent-and-secure-rbac.rst#20241-release-timeline19:42
sean-k-mooneyso as of this release and certenly for 2024.1 we shoudl be able to assume barbican has the behavior of enforce_scope=true19:43
sean-k-mooney*2024.219:46
melwittsean-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 be19:48
sean-k-mooneymelwitt: it looks like oslo has not deprecate the option or change the default yet 19:48
sean-k-mooneyhttps://github.com/openstack/oslo.policy/blob/master/oslo_policy/opts.py#L27-L3619:48
JayFI suspect it's reasonably common19:48
melwittsame..19:48
JayFIronic was configured that way (enforce_scope=False) by default until this cycle19:48
sean-k-mooneyJayF: right so it looks like we did not make progress on changing the default and removing the option this cycle19:49
melwittsean-k-mooney: yeah oslo_policy hasn't yet but barbican defaulting it https://github.com/openstack/barbican/blob/master/barbican/common/config.py#L357-L36119:49
sean-k-mooneyi remember this commign up in the last ptg19:49
sean-k-mooneymelwitt: so we can do soemthing like this19:50
sean-k-mooneywe can either use  our new default value to infer barbicans19:51
sean-k-mooneyand check for creator based on that or just catch the excption late19:51
sean-k-mooneyonce htis cant be turned off in barbican19:51
sean-k-mooneywe can drop the check in nova19:51
sean-k-mooneyand just rely on member19:51
melwittI 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 assumption19:52
sean-k-mooneywhat that will actully mean is by default we wont need to check19:52
sean-k-mooneyit 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 key19:53
melwitter, or it would be assuming that barbican is configured the same. which it may not19:53
sean-k-mooneyso its better then nothign for the small subset of pepole who diverge form the defaults19:53
sean-k-mooneyright alghough you are not really ment to mix and match enfoce_scope19:54
sean-k-mooneyi mean i guess it depends on how expensive the check is19:54
sean-k-mooneyi dont know if oslo midelware gives us a list of all the roles on the token already19:55
sean-k-mooneyif it does and its just a map lookup19:55
sean-k-mooneythen it cheap and we can alwasy do it19:55
sean-k-mooneyif its an api call to keystone on every spawn with this feature that when we might want to optimise19:55
melwittI 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 something19:57
sean-k-mooneyya 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 that19:59
gmannsean-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 service20:42
gmannfor nova, it is enabled by default, this is where we override the default https://github.com/openstack/nova/blob/13ccaf75f61a19ba11f39b63052bcef5dfbce91f/nova/policy.py#L5120:42
sean-k-mooneygmann: yep i know we have it enabled20:43
gmannWe enabled them by default since Antelope release20:43
sean-k-mooneyright but all project were ment to be enbaled by default last cycle20:44
sean-k-mooneyi remember that we disucssed this last ptg20:44
sean-k-mooneyand that they had not got tha tfar20:44
sean-k-mooneyso i tought we were trying to do that for 2024.120:44
gmannit 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 slow20:46
sean-k-mooneyit might be better at this point to flip the default in olso and make project explcity opt out20:47
gmannyeah, 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-mooneyack20:48
gmannsean-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/+/90886220:48
sean-k-mooneywe 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.220:49
sean-k-mooneygmann: thanks20:49
gmannI 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-mooneygmann: https://review.opendev.org/c/openstack/governance/+/908862/6/reference/runtimes/2024.2.rst#61 minior nit but over all this looks fine to me20:51
sean-k-mooneygmann: well we cant basedon the slurp process20:51
sean-k-mooneygmann: oslo have not deprecated the options yet20:51
gmannyes20:51
sean-k-mooneyso we cant remove until the deprecateion goes out in 2025.1 so 2025.2 woudl be the absolute earliest it coudl be removed now20:52
gmannyeah, we need it deprecated at least for 2025.1 20:52
gmannI 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
opendevreviewmelanie witt proposed openstack/nova-specs master: Re-propose specs for ephemeral encryption  https://review.opendev.org/c/openstack/nova-specs/+/90765422:08
*** kopecmartin_ is now known as kopecmartin22:50

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