Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-03-06
10:11:49 Uggla bauzas, gibi, question are the test_migration tests running when we use the nova manage db sync command ?
10:12:10 bauzas afaik nope
10:16:28 Uggla bauzas, ok.
10:52:52 bauzas ratailor__: I don't see a novaclient change for the 2.96 microversion
10:53:01 bauzas are you planning to deliver it this cycle ?
10:53:17 bauzas ratailor__: https://review.opendev.org/q/topic:%22list-requested-az%22
10:53:53 bauzas I +2d the sdk one and the osc one
10:56:14 bauzas we shall at least bump https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py
10:56:55 bauzas example of a noop client change https://github.com/openstack/python-novaclient/commit/85e4f08309490fa2ab6f0b581b3d645d2dbb5c4b
11:37:57 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
12:14:28 ratailor bauzas, ack. I will submit a patch for that adding noop client changes today. Thanks for reminding.
12:30:58 sean-k-mooney stblatzheim: if i recall correctly you want to back port this one more time after that to zed correct
12:32:02 stblatzheim correct
12:33:58 sean-k-mooney cool
12:34:23 sean-k-mooney im just capturing a comment for prosperity in the backport but its looks like a clean backport to me
12:39:54 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:53:48 opendevreview Merged openstack/nova master: Implement add_consumer, remove_consumer KeyManager APIs https://review.opendev.org/c/openstack/nova/+/896100
12:58:57 opendevreview Rajesh Tailor proposed openstack/python-novaclient master: Bump microversion to 2.96 https://review.opendev.org/c/openstack/python-novaclient/+/911575
13:06:19 ratailor bauzas, for your reference https://review.opendev.org/c/openstack/python-novaclient/+/911575
13:07:29 bauzas ratailor: +2d
13:07:35 ratailor bauzas, Thanks!
13:07:40 bauzas sean-k-mooney: gibi: could you please look at https://review.opendev.org/c/openstack/python-novaclient/+/911575 ?
13:09:39 sean-k-mooney am sure
13:23:51 stblatzheim thank you sean-k-mooney :)
15:32:30 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:33:00 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:45 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:40:18 dansmith from the outside, I don't think I can see anything about why this failed other than "not enough hosts"
15:41:46 dansmith maybe we should have a "set up encryption" action event or something so we can see that's what actually failed?
15:50:14 opendevreview Vlad Gusev proposed openstack/nova stable/zed: Unbind port when offloading a shelved instance https://review.opendev.org/c/openstack/nova/+/908694
16:00:02 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:31 dansmith cool
16:57:58 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
17:24:40 dansmith melwitt: just to restate what I said with more context:
17:25:08 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:16 dansmith so adding fixes to previous stuff in there just makes it bigger
17:26:22 melwitt dansmith: yeah, I agree that makes sense
17:27:21 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:28:59 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:30:33 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:50:18 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:57:49 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:58:44 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
18:02:54 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:04:23 melwitt ++
18:44:10 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
19:17:00 dansmith sean-k-mooney: melwitt confirmed with TPM: https://paste.openstack.org/show/bYK59AaAMr67tn9p56zP/
19:17:24 sean-k-mooney ack so that only works today because scope enforcement is disabled
19:17:29 sean-k-mooney right
19:17:53 sean-k-mooney well that or users need to have the creator role
19:18:13 melwitt dansmith: ok, cool, thanks
19:18:18 sean-k-mooney oh re reading melwitt comment
19:18:35 sean-k-mooney so createor shoudl not be required now and member shoudl be enouch with new policy is that correct
19:18:42 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:19:02 sean-k-mooney ok so that also explains why this worked when we tested it with the new isntaller
19:19:10 sean-k-mooney we are already enabeld the new SRBAC stuff there
19:19:12 melwitt and scope enforcement is enabled by default. it's just in devstack it defaults to False
19:19:29 sean-k-mooney ack
19:19:58 melwitt ah, yeah
19:20:02 melwitt yeah, I'll add these details to the spec too in regards to the role, like when it's needed
19:20:33 sean-k-mooney cool gibi manually checked vtpm when we were adding barbican supprot. weill have automatic testing in the next few weeks
19:21:06 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:26 sean-k-mooney our downstrema docs for vtpm dont mention this as far as im aware but ill check quickly
19:22:22 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:49 sean-k-mooney ya so we dont which makes me think that creator has not been created for a while
19:23:52 sean-k-mooney well that or there are two posiblities i guess tripleo deployed wallaby such that member was enouch
19:24:02 sean-k-mooney or the same tempest change was copied into our jobs
19:26:16 sean-k-mooney ah our job has the barbican plugin so we would not have seen it either way
19:26:17 sean-k-mooney https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/.zuul.yaml#L114
19:26:39 dansmith not sure why you say that.. I'm just using the barbican plugin
19:27:05 sean-k-mooney our whitebox test are using the default roles created for tempest
19:27:31 sean-k-mooney dansmith: and as melwitt noted https://github.com/openstack/barbican/blob/master/devstack/lib/tempest#L9-L12
19:27:50 sean-k-mooney the tempest config tempest_roles key gets creator added
19:28:35 sean-k-mooney https://github.com/openstack/tempest/blob/master/tempest/config.py#L64-L66
19:28:50 sean-k-mooney so all user created by tempest woudl hae the creator role
19:28:52 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:53 dansmith yes
19:29:12 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: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:30:21 sean-k-mooney my guess is 17.1 is configuring barbica so that member works
19:30:34 dansmith yeah that I don' tknow
19:35:59 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:38:55 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:39:34 sean-k-mooney anyway with that in mind do we still want ot have a check for this in the api
19:39:53 sean-k-mooney given we shoudl be using the new defaults in 2024.1 across all services
19:41:42 sean-k-mooney looking at https://github.com/openstack/governance/blob/48d090643e7faf138b8f4e19f4a2915a20e1a873/goals/selected/consistent-and-secure-rbac.rst#20231-release-timeline
19:42:11 sean-k-mooney barbica had supprot for enforce_new_defaults=True in antelope
19:42:26 sean-k-mooney and in 2024.1 oslo is ment to remvoe enforce_scope
19:42:29 sean-k-mooney https://github.com/openstack/governance/blob/48d090643e7faf138b8f4e19f4a2915a20e1a873/goals/selected/consistent-and-secure-rbac.rst#20241-release-timeline
19:43:23 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:46:01 sean-k-mooney *2024.2
19:48:16 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:40 sean-k-mooney melwitt: it looks like oslo has not deprecate the option or change the default yet
19:48:42 sean-k-mooney https://github.com/openstack/oslo.policy/blob/master/oslo_policy/opts.py#L27-L36
19:48:44 JayF I suspect it's reasonably common
19:48:57 melwitt same..
19:48:58 JayF Ironic was configured that way (enforce_scope=False) by default until this cycle
19:49:38 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:48 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:51 sean-k-mooney i remember this commign up in the last ptg

Earlier   Later