| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-03-11 | |||
| 09:56:49 | sahid | I think it should be an interesting feature, don't you think? | |
| 09:56:57 | sean-k-mooney | in general no :) | |
| 09:57:14 | sean-k-mooney | we could add someign like disablign an az | |
| 09:57:23 | sean-k-mooney | it has a staus but it does nothing | |
| 09:57:25 | sahid | ahah ...I hould have bet for your response :-) | |
| 09:57:45 | sean-k-mooney | today the status fo an az is just if any compute service is up and not disabled | |
| 09:58:02 | sean-k-mooney | sahid: why do you want to disable it? | |
| 10:00:40 | sahid | sean-k-mooney: it's to validate the resilience if we lose an AZ | |
| 10:00:52 | sahid | they do such check for everything | |
| 10:01:20 | sean-k-mooney | AZ are not for fault tollerance | |
| 10:01:33 | sean-k-mooney | so if your usign them for that you are starting form a broken foundation | |
| 10:01:53 | sahid | it's not the point | |
| 10:05:15 | sean-k-mooney | allowing an az to be disabled externally woudl be an api change and need a spec. im not entirly sure that a good thing but its not terible | |
| 10:05:38 | sean-k-mooney | today you could jsut disbale the computes theat are in an az to get the same effect | |
| 10:07:18 | sahid | sean-k-mooney: it's basically what we are going to do, but they are lot of computes to disable I was trying to think about something else | |
| 10:08:17 | sahid | i don't say it's something nova wants, perhpas it's something useful only for us | |
| 10:08:49 | sean-k-mooney | the problem is really what are the semantics | |
| 10:08:57 | sean-k-mooney | do we filter it form the list of AZs | |
| 10:09:31 | sean-k-mooney | do we impact any lifecycle operation on hosts assocated with the az | |
| 10:09:42 | sean-k-mooney | i.e. disabel reboot? start? | |
| 10:10:18 | sahid | from our use case it is just about to stop provisoning on a specific az | |
| 10:10:51 | sahid | wich may beuseful for upgrade or deployment if we can do that easily | |
| 10:10:54 | sean-k-mooney | i feel like this would be a new trait added to all host of a given az and an prefilter to forbid that trait | |
| 10:16:36 | sahid | sean-k-mooney: in that way we don't need an API change, right? | |
| 10:17:04 | sean-k-mooney | no you still do if you want a api call to be able to disable the az | |
| 10:17:21 | sean-k-mooney | if you just want to add the trait manually you would not need an api change | |
| 10:17:40 | sean-k-mooney | you can do that with the aggreate set commands i belive | |
| 10:18:19 | sahid | yes, probably having an API call is better, your right | |
| 10:18:41 | sahid | than doing some tweaks on resources | |
| 10:19:37 | sahid | should I start to think about it, it is something that nova would be interested? | |
| 10:19:58 | sean-k-mooney | it looks like we never merged the helper command to set a trait on all RPs in an aggreate | |
| 10:20:34 | sean-k-mooney | so you would have ot loop over all of them and set it one by one without an api call on the nova side | |
| 10:21:03 | sean-k-mooney | which is the same or more work then disabling all the computes | |
| 10:23:03 | sahid | yes that is why having an api would make more sense if we go in that direction, but there is perhaps a different solution, to indicate to the scheduler that this az is disabled | |
| 10:23:24 | sahid | as it has to go throught all the aggregates | |
| 10:30:12 | sean-k-mooney | so the schduler does not do anything with AZs anymore directly, the az filter was remvoed 3 releases ago | |
| 10:30:59 | sean-k-mooney | we have had the abity to do az enforcement in placment for 3-4 years at this point | |
| 10:31:28 | sahid | oh i did not noticed that | |
| 10:32:15 | sean-k-mooney | the prefilter was added in rocky, became the default in xena and the filter was removed in bobcat | |
| 10:32:42 | sean-k-mooney | sahid: that why im saying this woudl jsut be a trait on the RPs | |
| 10:32:56 | sean-k-mooney | and we woudl usdate the pre-filter to add it as a forbiden trait | |
| 10:34:22 | sean-k-mooney | it would work the same way the compute status pre-filter does https://github.com/openstack/nova/blob/master/nova/scheduler/request_filter.py#L242-L255 | |
| 10:36:00 | sahid | yes.. that does not really make sense to loop over all the RPs, if we really have to do that I guess we can just create an API to disable all host per AZ | |
| 10:36:22 | sahid | but this is more something like orchestration | |
| 10:36:37 | sahid | so that does not make sens to have it in nova aswell i guess | |
| 10:40:42 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add service version for Epoxy https://review.opendev.org/c/openstack/nova/+/944017 | |
| 10:40:43 | opendevreview | Sylvain Bauza proposed openstack/nova master: Update min support for Flamingo https://review.opendev.org/c/openstack/nova/+/944018 | |
| 10:49:26 | opendevreview | Sylvain Bauza proposed openstack/nova-specs master: Move Epoxy implemented specs https://review.opendev.org/c/openstack/nova-specs/+/944019 | |
| 11:29:55 | opendevreview | sean mooney proposed openstack/nova master: only show standard image properties in server show. https://review.opendev.org/c/openstack/nova/+/942413 | |
| 11:30:19 | sean-k-mooney | gibi: ^ fixed the remaining sample tests for 2.100 | |
| 11:37:19 | andrewbonney | Hi all. If anyone has chance I'd appreciate a follow up review on a long-standing small bug fix: https://review.opendev.org/c/openstack/nova/+/919961 | |
| 11:45:52 | gibi | sean-k-mooney: cool, thanks, +2 | |
| 11:51:30 | sean-k-mooney | andrewbonney: the core of the change looks ok. i dont think there is really enough tetst coverage to prevent regressing this, would you mind add a functional test that assert the correct behavior when you shleve? | |
| 11:52:03 | andrewbonney | I'll take a look, thanks | |
| 12:09:45 | opendevreview | Takashi Kajinami proposed openstack/nova master: doc: Drop deprecated [api] auth_strategy https://review.opendev.org/c/openstack/nova/+/944028 | |
| 12:09:46 | opendevreview | Takashi Kajinami proposed openstack/nova master: doc: Remove non-existent [service_user] auth_strategy https://review.opendev.org/c/openstack/nova/+/944029 | |
| 13:10:22 | opendevreview | Tobias Urdin proposed openstack/nova master: Add minute to instance_usage_audit_period https://review.opendev.org/c/openstack/nova/+/941488 | |
| 13:56:08 | opendevreview | Andrew Bonney proposed openstack/nova master: Don't reset port dns_name when shelving instances https://review.opendev.org/c/openstack/nova/+/919961 | |
| 13:58:25 | andrewbonney | sean-k-mooney: ^ hopefully that's better. Will see what CI thinks, but tests work locally | |
| 14:00:26 | sean-k-mooney | andrewbonney: ya assoming that funtional test passes it actully assert the behavior you wanted to change | |
| 14:00:40 | sean-k-mooney | lets see if ci is happy | |
| 14:00:48 | sean-k-mooney | andrewbonney: thanks for the update | |
| 14:01:49 | sean-k-mooney | andrewbonney: im a little conferned with how you implemeneted the list_exteions overried by the way | |
| 14:02:09 | andrewbonney | Happy to take advice - that's a copy from something similar in a regression test | |
| 14:02:15 | sean-k-mooney | i think you are only modifyign the neutron fixture that is local to this test | |
| 14:02:31 | sean-k-mooney | but its very close to a patten that can leak changes between tests | |
| 14:03:37 | sean-k-mooney | andrewbonney: https://github.com/openstack/nova/blob/a329c103cbc864591f232b195016407e407bdb5d/nova/tests/functional/regressions/test_bug_1888395.py#L32-L49 ya its probaly fine | |
| 14:03:54 | andrewbonney | That's the one | |
| 14:05:13 | sean-k-mooney | i wrote that so if its wrong its on me anyway :) | |
| 14:05:18 | andrewbonney | :) | |
| 14:09:29 | opendevreview | Merged openstack/python-novaclient stable/2025.1: Update .gitreview for stable/2025.1 https://review.opendev.org/c/openstack/python-novaclient/+/943762 | |
| 14:09:54 | opendevreview | Dan Smith proposed openstack/os-traits master: Add HW_PCI_ONE_TIME_USE trait https://review.opendev.org/c/openstack/os-traits/+/944049 | |
| 14:11:35 | opendevreview | Merged openstack/python-novaclient stable/2025.1: Update TOX_CONSTRAINTS_FILE for stable/2025.1 https://review.opendev.org/c/openstack/python-novaclient/+/943763 | |
| 14:23:26 | opendevreview | Merged openstack/nova master: Add service version for Epoxy https://review.opendev.org/c/openstack/nova/+/944017 | |
| 14:34:38 | opendevreview | Dmitriy Chubinidze proposed openstack/nova master: doc: nova service_user wrong auth_url https://review.opendev.org/c/openstack/nova/+/938680 | |
| 14:35:01 | dansmith | sean-k-mooney: gibi: do we allow passing through a PF like a whole device? it seems like that's probably a bad idea, unless we check that a PF with VFs has none of those VFs available for use by nova, right? | |
| 14:35:16 | sean-k-mooney | yes we do | |
| 14:35:48 | sean-k-mooney | without pci in placement we only allow pfs if non of the VFs are allocated | |
| 14:36:05 | sean-k-mooney | with pci in placment you can only list the PF or the VFs | |
| 14:36:13 | sean-k-mooney | but not both for the same device | |
| 14:36:20 | dansmith | allocated...currently? or available for allocation at all? | |
| 14:36:27 | sean-k-mooney | allcoated currently | |
| 14:36:34 | dansmith | wow, okay | |
| 14:36:46 | sean-k-mooney | it was a usecase that telcos really wanted | |
| 14:36:47 | dansmith | either way, if pci in placement has a strict either-or rule, that helps | |
| 14:37:11 | sean-k-mooney | ya to make the accounting work we could not have it chaging dynmicaly | |
| 14:37:12 | dansmith | can I tell that something is a virtual function just because it has the physfunc (or whatever) in its /sys directory? | |
| 14:37:28 | sean-k-mooney | yes | |
| 14:37:42 | dansmith | cool | |
| 14:37:46 | sean-k-mooney | we look at the pci capablites which are reported in the nodedevxml | |
| 14:37:48 | gibi | dansmith: yep PCI in Placement has a strict either or check | |
| 14:37:53 | dansmith | cool | |
| 14:38:18 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/host.py#L1373-L1430 | |
| 14:38:29 | sean-k-mooney | that is how th elibvirt driver decied what type of device it is | |
| 14:39:35 | gibi | https://github.com/openstack/nova/blob/0d484ce37d86e989c8abdf57aec5e334f68206ef/nova/tests/functional/libvirt/test_pci_in_placement.py#L206-L239 this is the functional test proving that nova rejectes dependent devices if pci in placement is enabled | |
| 14:59:46 | opendevreview | sean mooney proposed openstack/nova master: only show standard image properties in server show. https://review.opendev.org/c/openstack/nova/+/942413 | |
| 14:59:46 | opendevreview | sean mooney proposed openstack/nova master: [tests] add priting of sample and templete paths https://review.opendev.org/c/openstack/nova/+/944054 | |
| 14:59:58 | sean-k-mooney | dansmith: ^ i think thats what you wanted | |
| 15:05:19 | opendevreview | Dan Smith proposed openstack/nova master: [tests] Add printing of sample and template paths https://review.opendev.org/c/openstack/nova/+/944054 | |
| 15:05:55 | dansmith | sean-k-mooney: got 'em thanks | |