| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-03 | |||
| 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 | |
| 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 | dansmith | we'd need to add a generic metadata blob to service | |
| 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:40 | dansmith | nope | |
| 13:43:58 | sean-k-mooney | thats also not partically nice but ok | |
| 13:44:24 | dansmith | not nice because it requires db changes? or not nice for other reasons? | |
| 13:44:33 | sean-k-mooney | the db changes | |
| 13:44:38 | sean-k-mooney | if its just for this | |
| 13:44:48 | sean-k-mooney | if it was like instance_system_metadta | |
| 13:44:55 | sean-k-mooney | and we had other usecases i woudl care less | |
| 13:45:06 | dansmith | yeah, well, I mean.. something will require changes.. but I figure we might be able to use it for other things too | |
| 13:45:30 | sean-k-mooney | so you prefer doign ti via discover host to limit the creds | |
| 13:45:53 | dansmith | well, we already have a discovery process to do very similar things | |