Earlier  
Posted Nick Remark
#openstack-nova - 2023-05-03
08:31:22 sean-k-mooney its auto geneerated using a tool
08:31:48 sean-k-mooney tox -e venv reno new zed-milestone-3
08:32:16 sean-k-mooney reno is the tool we use to create releasenotes
08:32:31 sean-k-mooney dvo-plv_:^
08:37:30 dvo-plv_ thank you
11:33:03 opendevreview Danylo Vodopianov proposed openstack/nova master: Packed virtqueue support was added. https://review.opendev.org/c/openstack/nova/+/876075
11:53:15 opendevreview Amit Uniyal proposed openstack/nova stable/wallaby: fup: Print message logging uncaught nova-manage exceptions https://review.opendev.org/c/openstack/nova/+/877334
11:54:10 opendevreview Danylo Vodopianov proposed openstack/nova-specs master: VirtIO PackedRing Configuration support https://review.opendev.org/c/openstack/nova-specs/+/868377
12:15:15 dvo-plv_ gibi: I have resolved your comment at this bp https://review.opendev.org/c/openstack/nova-specs/+/868377
12:18:18 gibi dvo-plv_: look good to me
12:23:14 opendevreview Danylo Vodopianov proposed openstack/nova-specs master: VirtIO PackedRing Configuration support https://review.opendev.org/c/openstack/nova-specs/+/868377
12:38:29 dvo-plv_ I fixed pep8 validation. Should I do something more for further bp activities?
12:38:54 sean-k-mooney im just waitign for ci to report back im still happy with it so ill readd +2 once its green
12:39:08 sean-k-mooney oh its already repoted back
12:40:18 sean-k-mooney gibi: care to send it on its way https://review.opendev.org/c/openstack/nova-specs/+/868377
12:43:03 gibi sean-k-mooney, dvo-plv_ : done
12:47:55 dvo-plv_ Great. So spec file is approved. Then we have to wait for code review ? https://review.opendev.org/q/topic:bp%252Fvirtio-packedring-configuration-support
12:58:51 opendevreview Merged openstack/nova-specs master: VirtIO PackedRing Configuration support https://review.opendev.org/c/openstack/nova-specs/+/868377
13:05:38 sahid quick question regarding host aggregate and AZ
13:06:55 sahid we have noticed that when we add a compute host, that one is always considered in the AZ nova (the one that is by default configured in default_avalibility_zone)
13:07:29 sahid it seems that if we don't want this behavior to happen, we have to first add the host to the correct aggregate and then start nova-compute service
13:08:09 sahid the problem is that, it seems not possible to add in an aggregate a host that has not been "registered" by a service like nova-compute, right?
13:09:18 sean-k-mooney sahid: that not how it works
13:09:42 sean-k-mooney if you dont add a host to an aggreate with az metadta
13:09:43 sahid so during deployement of a new compute host we always have that window where the host is considered in AZ nova (this az does not exist in our deployement) until that we set the host to the correct aggregate
13:10:26 sean-k-mooney if you dont add a host to an aggreate with az metadta then its is considerd part of default_availability_zone
13:10:30 sahid (a aggregate with ZA metadata, yes)
13:10:50 sahid sean-k-mooney: yes we are in the same page
13:11:08 sean-k-mooney sahid: yes ther is no way to atomically ahve a comptue node com up and register in an az
13:11:38 sean-k-mooney sahid: if you want to prevent ti beign selected you can make the service register in a disabeld state
13:12:01 sahid i think it may be possible to achieve that if we allow to add an host that does not yet exist in a aggregate (that has az metadata), right?
13:12:13 sahid sean-k-mooney: ahh interesting point
13:12:43 sahid what do you mean by "selected"?
13:12:53 sahid I don't want that nova az appears
13:12:58 sean-k-mooney considerd as a valid host for scheduling
13:13:03 sahid because it's confusing for users
13:13:09 sahid ah...
13:13:14 sean-k-mooney that is not somethign you can do currently
13:13:45 sahid no no, from users perspective is not really good to see this "nova" az appearing and disapearing
13:13:53 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.enable_new_services
13:14:08 sean-k-mooney sahid: well many deployment just use the nova az
13:14:22 sean-k-mooney a new feature could be added to hide az perhaps
13:14:26 sean-k-mooney but its workign as intended
13:14:58 sahid and what about to give ability to add a host that does not yet exists to an aggregate?
13:15:06 sean-k-mooney i.e. we coudl add a config option to hide the defautl az or add a metadata parmater perhasp
13:15:17 sean-k-mooney sahid: i dont really like that option
13:15:38 dvo-plv_ gibi, sean-k-monney: Great. So spec file is approved. Then we have to wait for code review ? https://review.opendev.org/q/topic:bp%252Fvirtio-packedring-configuration-support
13:15:39 sean-k-mooney i could maybe see adding a cofnig option to let the compute node know what az to regester in by default
13:16:07 sean-k-mooney dvo-plv_: ya but at this point provided all the tests ectra are in place and we are ok with the code all the admin is done
13:16:23 sahid this already exist right? https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_availability_zone
13:16:37 sahid but this work for deployment with one az
13:17:37 sahid i had feeling that configuring the host to the aggregate, then starting nova-compute on it would have been a not so bad solution
13:18:03 sahid nova-compute at start could have been able to be registered in the right way
13:18:36 dvo-plv_ sean-k-monney: Do you mean additional test for packed option from our side, or zuul verification ?
13:19:07 sahid we need to find a solution so when we start nova-compute for the first time it is be able to determine is AZ properly
13:21:26 sean-k-mooney sahid: well compute agents are not ment to kwno what az they are in realy
13:21:37 sean-k-mooney same as they are not ment to really knwo what cell they are in
13:22:28 sean-k-mooney sahid: default_availability_zone is what is makign it show as nova
13:22:36 sean-k-mooney but that is not used by the compute agent
13:23:01 sean-k-mooney the nova az does not actully exsit as a host aggreate either
13:23:17 sean-k-mooney or rather the default_availability_zone does not actully exist in the database
13:24:08 sean-k-mooney that parmater is just read by the api to use as a default when the compute service is not associated with an az. bauzas can correct me if that is wrong
13:24:20 bauzas on a meeting now
13:24:37 bauzas explain me quickly the issue, please ?
13:24:57 sean-k-mooney bauzas: sahid would like a way for compute agents to auto register to an az
13:25:07 sean-k-mooney so that they dont end up in the default_availability_zone i.e. nova
13:25:27 sean-k-mooney because they dont wnat that az to come and go as they are provisioning new servers
13:26:08 sean-k-mooney we coudl adress that multiple ways but it would be a new feature in any case
13:26:10 bauzas so, automatically adding a compute service to an aggregate ? well, some script can do it
13:26:26 sean-k-mooney it can yes which is what we expect to be done now
13:26:30 bauzas nothing I see for needing Nova to do it automatically
13:26:51 sean-k-mooney there is a small window btween the compute node starting and being able to add it at the api
13:27:03 bauzas they can disable it by default, right?
13:27:15 sean-k-mooney the az will still show up while the ocmptue is disabled
13:27:29 sean-k-mooney its the default az they want to hide not nessisarly the compute node
13:27:32 dansmith but aggregates are in the api database
13:27:34 bauzas sure, but that's an operator point
13:27:51 dansmith auto-registering to an az would require compute->conductor->apidb right?
13:27:52 sean-k-mooney dansmith: yep which is why i said this is not really somthing the compute agent should know about via config
13:28:03 sean-k-mooney dansmith: ya it woudl need an up call
13:28:06 dansmith okay good, I thought you were arguing _for_ doing that
13:28:15 bauzas again, any script can do it, I don't see *why* nova should support it
13:28:15 sean-k-mooney no not really
13:28:36 dansmith it also breaks several things: 1. computes don't know their az and 2. no upcalls
13:28:55 sean-k-mooney yep
13:29:16 sean-k-mooney so either we add config drive api behavior ( allow hiding the default az via a api config option)
13:29:27 bauzas plus the fact that we check race conditions in the API, not by the compute service
13:29:29 sean-k-mooney or we make the default az a reall az/hostaggerte in the db
13:29:29 sahid it's why i was asking to give ability for operator to add in aggregate host that does not yet exist
13:29:34 sean-k-mooney or we just dont change things
13:29:57 sahid bauzas: it's about an user experience
13:30:21 sean-k-mooney sahid: we technially dont have a forign key that would prevent that so we could
13:30:21 bauzas everytime you're adding a host to an aggregate, we synchronously check that AZs are correct
13:30:55 sean-k-mooney it might be workable
13:30:55 sean-k-mooney if we comine that with the stable uuid feature
13:30:55 sahid they see nova appearing
13:30:57 sean-k-mooney ie preallcoat the uuid that would be used for the comptue somehow but that is still kind of messy
13:30:59 bauzas sahid: I think we explained that by default nova supports one AZ
13:31:20 bauzas that doesn't mean that nova will *check* hosts
13:32:04 sean-k-mooney i think we check that there is a host_mapping today before allowing you to add a host to a host aggreate

Earlier   Later