| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-03 | |||
| 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 | sean-k-mooney | no not really | |
| 13:28:15 | bauzas | again, any script can do it, I don't see *why* nova should support it | |
| 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 | sahid | it's why i was asking to give ability for operator to add in aggregate host that does not yet exist | |
| 13:29:29 | sean-k-mooney | or we make the default az a reall az/hostaggerte in the db | |
| 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 | bauzas | everytime you're adding a host to an aggregate, we synchronously check that AZs are correct | |
| 13:30:21 | sean-k-mooney | sahid: we technially dont have a forign key that would prevent that so we could | |
| 13:30:55 | sahid | they see nova appearing | |
| 13:30:55 | sean-k-mooney | if we comine that with the stable uuid feature | |
| 13:30:55 | sean-k-mooney | it might be workable | |
| 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 | |
| 13:32:06 | bauzas | only the operators know whether the AZ that the user uses is actually a right AZ or just a fake one | |
| 13:32:33 | dansmith | sahid: I assume the goal is so that an operator adding a new compute can tell the compute where it wants to plug in and have that happen when it first registers itself, instead of adding, registering, and then having to go back and add it to an aggregate right? | |
| 13:32:53 | bauzas | as we also loudly say that operators shall NEVER create 'nova' AZs, I don't see the problem | |
| 13:34:43 | sahid | sean-k-mooney: yes today, if you try to do that with an host that does not "exist" you receive an error | |
| 13:37:58 | sahid | dansmith: yes it's mostly that, today we start the service and then add the host to the correct aggregate, during this window, nova appears in the list of AZs | |
| 13:38:28 | sahid | we want to do the opposite (if possible), by configuring the host aggregate and then starting the service | |
| 13:38:36 | dansmith | sahid: so is it just a "day 0" thing, or do you want compute to be able to change its own az if you change its config and restart? | |
| 13:38:46 | sahid | in that way we avoid that "nova" | |
| 13:39:01 | sahid | just a day 0 thing | |
| 13:40:04 | dansmith | so, what about something like allowing metadata on a service, which you can configure in nova.conf for the compute, and then have the discover_hosts thing look for a "desired_az" or "desired_aggs" key and do the needful during discovery (which has to happen anyway)? | |
| 13:40:21 | dansmith | that way no upcall, and it's just "desired" and "metadata" and not "this is my az" | |
| 13:40:26 | dansmith | doesn't work after day zero | |
| 13:41:18 | dansmith | we could probably use metadata on a service for other things | |
| 13:41:35 | dansmith | I'd have to think some more.. I'm trying to listen to a meeting right now too | |
| 13:42:00 | sean-k-mooney | dansmith: we could also avoid the upcall by having the nova comptue just call the nova api driectly | |
| 13:42:07 | sahid | this should resolve our case for sure and is a bit like what sean-k-mooney mentioned | |
| 13:42:31 | dansmith | sean-k-mooney: it needs admin credentials though which would be unfortunate I think | |
| 13:42:46 | sean-k-mooney | well at least teh service role | |
| 13:42:52 | sean-k-mooney | but ya | |
| 13:43:00 | dansmith | yeah, not full admin hopefully, but still | |
| 13:43:11 | sean-k-mooney | where where you thinking of stashing the desired az | |
| 13:43:34 | sean-k-mooney | i dont think we have a db table we coudl use for that in the cell db currenlty | |
| 13:43:34 | dansmith | we'd need to add a generic metadata blob to service | |
| 13:43:40 | dansmith | nope | |
| 13:43:58 | sean-k-mooney | thats also not partically nice but ok | |