| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-03 | |||
| 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 | |
| 13:46:09 | dansmith | lemme finish listening to this meeting for the next 15 minutes and then I can think a little more | |
| 13:51:01 | sahid | this should resolve our case for sure and is a bit like what sean-k-mooney mentioned | |
| 13:51:07 | sahid | oops sorry | |
| 13:56:09 | sahid | i've create bug report here, https://bugs.launchpad.net/nova/+bug/2018398 in case that we consider it's as valid and we want to do something to improve users experience :-) | |
| 13:57:02 | dansmith | sahid: s/users/operators/ so we're clear which "users" we're talking about | |
| 13:57:38 | dansmith | but yeah, I think this would be a nice behavior for operators, as long as we can do it within the other constraints and design points we have | |
| 13:57:52 | bauzas | sahid: so thanks for the bug report, now I better understand your concern | |
| 13:58:02 | bauzas | lemme check one thing tho | |
| 13:59:18 | bauzas | sahid: so, say your operator defined two AZs : AZ1 and AZ2 | |
| 13:59:32 | bauzas | hostA is in AZ1, hostB in AZ2 | |
| 13:59:34 | sahid | dansmith: wait, perhaps there is something that we are not doing correctly, but it's really our users which see those AZs in our interfaces | |
| 13:59:42 | bauzas | now, he gonna add hostC | |
| 14:00:19 | bauzas | once he registers hostC, then it appears a third AZ in the AZ list which is 'default_availability_zone' ie. 'nova' | |
| 14:00:31 | bauzas | I get the problem | |
| 14:00:32 | sahid | when they create an instance they can select the AZ | |
| 14:00:36 | bauzas | nown my question | |
| 14:00:51 | sahid | bauzas: yes rights | |
| 14:00:55 | bauzas | why isn't the default availabilty zone be either AZ1 or AZ2 ? | |
| 14:01:13 | bauzas | we just use that value to fake AZs | |
| 14:01:26 | dansmith | sahid: I know users see AZs, but users will not see this compute node feature | |
| 14:01:29 | bauzas | but this is not meaning that instances are automatically scheduled to that ZA | |
| 14:01:32 | bauzas | AZ* | |
| 14:01:36 | sahid | dansmith: ack | |
| 14:01:56 | bauzas | the default value for sending an instance to an AZ is default_schedule_zone | |
| 14:02:03 | bauzas | which is None by default | |
| 14:02:37 | dansmith | bauzas: oh right, I always forget about this difference | |
| 14:02:42 | dansmith | there are two conf knobs right? | |
| 14:03:52 | bauzas | yes | |
| 14:04:36 | bauzas | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_schedule_zone is for pushing new instances to a specific AZ automatically | |
| 14:05:07 | bauzas | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_availability_zone is just for showing a AZ if none exists | |
| 14:05:35 | bauzas | in a context where some AZs already exist, the solution is just to set the latter option to an existing AZ | |
| 14:05:38 | dansmith | bauzas: but it doesn't actually put the compute there right? | |
| 14:05:45 | bauzas | no | |
| 14:05:49 | dansmith | it's like faked in the api? | |
| 14:05:53 | sean-k-mooney | yep | |
| 14:05:54 | bauzas | " This option determines the default availability zone for ‘nova-compute’ services, which will be used if the service(s) do not belong to aggregates with availability zone metadata." | |
| 14:06:02 | sean-k-mooney | its not used by the compute service at all | |
| 14:06:40 | sean-k-mooney | you could have discover host use it if its set to a real az | |
| 14:06:53 | dansmith | yeah, so now does that help? I mean, it might help the "don't expose some other AZ for a window after adding the compute" but it doesn't help the mechanical operations of just dealing with the compute itself while adding | |
| 14:07:11 | bauzas | dansmith: there are two different concepts that are hard to understand | |