Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-03-11
08:58:59 ralonsoh yes, you are right
08:59:06 ralonsoh in any case, I'll try this first
09:00:27 sean-k-mooney ralonsoh: if you can tell there is a rename
09:00:34 sean-k-mooney you can also do what is called a reshape
09:00:44 sean-k-mooney whish is the operation of moving allcoation between RPs
09:01:08 sean-k-mooney they are non tivial but its how we evovled the stucture over time
09:01:30 sean-k-mooney https://docs.openstack.org/api-ref/placement/#id86
09:02:58 sean-k-mooney so for a rename you would add the new rp, reshape the inventories/allocation from the old then delete the old RP
09:03:09 ralonsoh I don't think we need to implement this reshape (I think)
09:03:23 ralonsoh just remove the RP that is un-configured
09:03:32 sean-k-mooney ya in this case you dont
09:03:37 sean-k-mooney at least not for that jira
09:03:51 sean-k-mooney just letting you know that api exists if you need it in the future
09:04:13 ralonsoh for sure, good to know this!
09:51:53 sahid o/
09:52:31 sahid quick question guys, is there a way to stop provision on a specific AZ, or at least a way to do it
09:52:42 sahid I'm sure there is something but I can't remember how
09:54:36 sean-k-mooney sahid: no
09:54:45 sean-k-mooney sahid: not in general at least
09:54:59 sean-k-mooney you could proably hack it usign some of the filters
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

Earlier   Later