Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-03-05
19:28:10 sean-k-mooney melwitt: i think dansmith just had a typo so i assume its working ok now or htey havent gotten aroudn to restacking
19:28:47 melwitt thanks sean-k-mooney
19:30:09 melwitt also, regarding the policy changes in the DNM tempest jobs patch, I did that to cover as many tests as possible, so that _if_ someone had their policy set that way, to verify whether it works
19:30:09 stblatzheim sean-k-mooney: Can you give a W vote for https://review.opendev.org/c/openstack/nova/+/910616 ? It's stuck before gate tests :)
19:30:39 melwitt it's not a statement about it being the right thing to do
19:31:02 sean-k-mooney stblatzheim: it need another stabel core to reveiw
19:31:46 stblatzheim Who could I ping for this? :)
19:31:57 sean-k-mooney melwitt: would you have 5 mins for ^
19:31:58 dansmith melwitt: yeah I had a typo, not sure if it finished re-stacking or not
19:32:24 melwitt sean-k-mooney: sure, will look
19:32:39 melwitt dansmith: ack
19:33:39 dansmith sean-k-mooney: I looked at that yesterday and wanted to hear your take on your change of opinion
19:33:53 dansmith I read the bug and see neutron people saying it was wrong and implying the patch is correct,
19:34:17 dansmith but I didn't see any indication of "and yes this should be backported" since it presumably depends on what version(s) of neutron are in use in an older release
19:34:59 sean-k-mooney so the orginal patch tried to fix it by lookging for additon aports with a diffent device owner string
19:35:17 sean-k-mooney and i did not like that approch because it was wack a mole for every backend
19:35:31 sean-k-mooney the current patch checks if the subnet has dhcp enabled
19:35:41 dansmith oh I didn't see that it was a different approach earlier
19:35:49 sean-k-mooney and then use the enable_dhcp option to tell cloud init to use dhcp
19:36:42 opendevreview Merged openstack/nova master: Disconnecting volume from the compute host https://review.opendev.org/c/openstack/nova/+/877446
19:37:21 dansmith sean-k-mooney: yeah but it changes what it's looking at from neutron, but the assertion is the thing it's looking for (the dhcp flag I guess) is nowhere near new enough to be a problem for a backport?
19:37:27 sean-k-mooney dansmith: os thats why i changed my mind. im fine with looking at the dhcp_enabled field on the subnet to determin if we configure cloud init for static ips or dhcp
19:38:07 sean-k-mooney dansmith: let me read the bug i didnt see them respond
19:39:14 sean-k-mooney ok so quickly readin gthey change this bevhiro in vitoria
19:39:31 sean-k-mooney https://review.opendev.org/c/openstack/neutron/+/732364
19:39:32 stblatzheim enable_dhcp flag is there at least for 5 years (there was a try to fix this but not very well)
19:39:40 sean-k-mooney so that change broke the nova intengration
19:40:02 sean-k-mooney but i belive dhcp_enabled is much much older then that
19:40:44 dansmith sean-k-mooney: the patch description sort of sounds like this fixes it for OVN instead of OVS, so it just kinda seemed like this might be a "make it work for my situation" sort of thing
19:40:48 sean-k-mooney its part of the core subnet resouce https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/subnet.py#L109
19:41:04 stblatzheim https://github.com/openstack/nova/commit/c7f572d65b57e034c1391ed49d84f6e5f1d672ad
19:41:39 dansmith sean-k-mooney: cool, fair enough, just wanted to confirm.. I saw you were "hell no" and then suddenly +2 so just wanted to make sure I understood :)
19:41:43 sean-k-mooney dansmith: the pach makes use not use "does the a subnet has a dhcp port" be how we determin if the subnet has dhcp enabled
19:41:55 sean-k-mooney instead we directly read the enable_dhcp field
19:42:09 sean-k-mooney so we have test coverage for ml2/ovs in the ci as well
19:42:24 sean-k-mooney with the ovs_hybrid_plug job
19:44:17 sean-k-mooney from what i can tell enable_dhcp has been a vaild field since the creation of the api defintion in neutron-lib in 2017 and if im being honestly i think this was in quantum
19:44:21 sean-k-mooney so ya i think we are good
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 ++

Earlier   Later