| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-02 | |||
| 17:10:57 | sean-k-mooney | i would have preferd to do it at m1 | |
| 17:11:07 | sean-k-mooney | but i think ceph is a higher piority | |
| 17:12:27 | bauzas | I was under the impression that the nfs encryption was requiring a recent libvirt version but I could be wrong and mixing two things | |
| 17:15:26 | enriquetaso | mmmh, I'm not sure | |
| 17:15:51 | sean-k-mooney | i donthing think libvirt matters | |
| 17:15:59 | sean-k-mooney | but qemu-img might | |
| 17:16:03 | sean-k-mooney | and qemu | |
| 17:17:35 | enriquetaso | I can check and add this information on the spec if the feature need a min version of libvirt or qemu | |
| 17:18:55 | enriquetaso | okay, I'm going to disconnect now | |
| 17:19:01 | enriquetaso | thank you so much again | |
| #openstack-nova - 2023-05-03 | |||
| 07:52:51 | opendevreview | Amit Uniyal proposed openstack/nova master: Allow swap resize from non-zero to zero https://review.opendev.org/c/openstack/nova/+/857339 | |
| 08:09:14 | dvo-plv_ | Hello, All Could you pelase help me with file naming | |
| 08:09:37 | dvo-plv_ | opt/stack/glance/releasenotes/notes/zed-milestone-3-3e38697ae4677a81.yaml where should I get hash ( zed-milestone-....yaml) in this file ? | |
| 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 | |