| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-03-05 | |||
| 19:44:44 | sean-k-mooney | dansmith: thanks for follwoing up your right that i orgignally marked this as invalid | |
| 19:45:10 | sean-k-mooney | because i do think neutron broke there api contract when they change the poer owner but it was reasonable for use to fix in nova | |
| 19:45:20 | dansmith | yeah exactly :) | |
| 19:49:48 | dansmith | sean-k-mooney: stblatzheim: got it | |
| 19:50:07 | stblatzheim | :) | |
| 20:08:09 | melwitt | dansmith: the only other thing you will need to do is make sure that whatever user you want to work with encrypted local disks has the "creator" role assigned to them. the barbican devstack plugin adds it to some users it creates https://github.com/openstack/barbican/blob/master/devstack/lib/barbican#L278 but if you use a different user you will need to add the role to that user | |
| 20:13:41 | dansmith | oh interesting okay | |
| 20:17:01 | melwitt | the "creator" role is what barbican uses to allow creation of secrets | |
| 20:17:49 | dansmith | yeah I gathered :) | |
| 20:17:54 | dansmith | quite the intuitive name ;P | |
| 20:23:28 | opendevreview | melanie witt proposed openstack/nova master: docs: Remove warning about quota driver default change https://review.opendev.org/c/openstack/nova/+/911374 | |
| 22:29:16 | opendevreview | Merged openstack/nova stable/2023.2: Fix nova-metadata-api for ovn dhcp native networks https://review.opendev.org/c/openstack/nova/+/910616 | |
| 22:54:39 | opendevreview | Steven Blatzheim proposed openstack/nova stable/2023.1: Fix nova-metadata-api for ovn dhcp native networks https://review.opendev.org/c/openstack/nova/+/911070 | |
| #openstack-nova - 2024-03-06 | |||
| 06:14:48 | 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:50 | opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Separate OSError with ValueError https://review.opendev.org/c/openstack/nova/+/911395 | |
| 06:14:51 | opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Disconnecting volume from the compute host https://review.opendev.org/c/openstack/nova/+/911396 | |
| 06:24:18 | opendevreview | Amit Uniyal proposed openstack/nova stable/2023.2: Refactor vf profile for PCI device https://review.opendev.org/c/openstack/nova/+/905135 | |
| 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 | |