| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-10 | |||
| 14:36:42 | sean-k-mooney | one that has been there forever | |
| 14:36:44 | noonedeadpunk | ooopps | |
| 14:36:58 | bauzas | https://docs.openstack.org/nova/latest/admin/availability-zones.html | |
| 14:37:00 | sean-k-mooney | like litrally since i started workin on openstack 10 years ago | |
| 14:37:09 | bauzas | I wrote that in solid red | |
| 14:37:29 | sean-k-mooney | bauzas: ya i know. im just saying that what you expect and how thing are used in the wild dont actully agreee | |
| 14:37:33 | ratailor | sean-k-mooney, bauzas I took that name, because its easy to differentiate for endusers, who don't know anything about nova internals. | |
| 14:37:49 | bauzas | ratailor: read my comments | |
| 14:38:04 | ratailor | bauzas, ack. | |
| 14:38:29 | bauzas | endusers would wonder why their instance has a returned param saying 'requested_az' : "bar" without them asking for it | |
| 14:39:16 | bauzas | sean-k-mooney: sure, I understand people doing wild things are usual, but for those we also say "unsupported" | |
| 14:39:44 | noonedeadpunk | I then have a question towards default_availability_zone that you already discussed some time ago with damiandabrowski. As like in some usecases I see close to no other option rather then define default_availability_zone, for instance when cross_az_attach = False | |
| 14:40:13 | bauzas | ? | |
| 14:40:13 | bauzas | noonedeadpunk: default_schedule_zone you mean . | |
| 14:40:35 | bauzas | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_schedule_zone | |
| 14:40:47 | bauzas | ". The instance(s) will be bound to this availability zone " | |
| 14:41:00 | bauzas | ahah, third alternative name ! "bound_availability_zone" | |
| 14:41:24 | noonedeadpunk | yeah, sorry, default_schedule_zone | |
| 14:41:50 | bauzas | noonedeadpunk: what's your question with this option ? | |
| 14:42:57 | noonedeadpunk | So, when you have multiple AZs, and isolated storage in each AZ (so volumes can't migrate cross-AZ), and user does not provide AZ explicitly - VM will try to move between AZs, since it's not ending up in request_specs | |
| 14:43:03 | noonedeadpunk | unless default_schedule_zone is defined | |
| 14:46:07 | noonedeadpunk | nah, disregard, I already found answer to my "question" :) | |
| 14:46:59 | bauzas | noonedeadpunk: yeah, it depends on cross_az_attach value | |
| 14:47:05 | bauzas | if True, indeed | |
| 14:47:41 | bauzas | if False, nope, we'll automatically change the value of reqspec.az to the volume's az name | |
| 14:47:52 | bauzas | so it will be "pinned" or "bound" | |
| 14:48:11 | bauzas | even if the user "requested" something elsze | |
| 14:48:29 | bauzas | hence my concern on the ratailor's API parameter name | |
| 14:48:58 | bauzas | noonedeadpunk: how much your users know about Nova internals and the fact we have a DB table named "request_specs" ? | |
| 14:49:21 | noonedeadpunk | bauzas: I think it's true only _if_ volume was created first | |
| 14:49:31 | bauzas | the fact is that I don't like ourselves naming a new parameter "requested" if something else but the user changed it | |
| 14:49:39 | noonedeadpunk | bauzas: they don't give a sh*** about it :D | |
| 14:49:46 | bauzas | that's my point | |
| 14:50:29 | noonedeadpunk | Because if volume is being created together with server - reqspec.az is not populated then | |
| 14:50:32 | bauzas | noonedeadpunk: yeah, if you bfv your instance by asking nova to create a volume, then nova asks cinder for a new volume without passing the AZ | |
| 14:50:38 | ykarel | thx sean-k-mooney for your response yesterday re. https://bugs.launchpad.net/nova/+bug/2045785 | |
| 14:51:05 | ykarel | do you have link for the other tempest unfixed issue that you mentioned or link it into the bug ^ | |
| 14:51:14 | bauzas | noonedeadpunk: because (IIRC) we create the volume *before* we schedule | |
| 14:51:22 | ykarel | i will check later if it's same or some other issue | |
| 14:52:15 | noonedeadpunk | bauzas: but shouldn't then it be veeery close to usage of already existing volume? | |
| 14:52:27 | noonedeadpunk | Ie, you should be already be able to check AZ of that volume? | |
| 14:52:52 | bauzas | honestly, I need to remember the details | |
| 14:52:59 | bauzas | I also wrote a functional test for it | |
| 14:53:05 | noonedeadpunk | Yeah, no worries | |
| 14:53:06 | bauzas | so we could test | |
| 14:53:41 | bauzas | noonedeadpunk: you haven't responded to our question about your preference for naming the new parameter that ratailor would provide | |
| 14:54:03 | noonedeadpunk | We're just close to have each scheduler having it's own `default_schedule_zone` for some "random" provisionment | |
| 14:54:08 | bauzas | from an user point of view, I was arguing on the fact that 'requested AZ' is wrongly named | |
| 14:54:44 | bauzas | and I would prefer the new returned param to be something like 'pinned AZ' or 'bound AZ' | |
| 14:57:27 | noonedeadpunk | Sorry, I'm trying to come up with some extra comments to it | |
| 15:00:24 | noonedeadpunk | Well, given that indeed it's not "requested" per say, I think it may indeed being confusing | |
| 15:01:16 | noonedeadpunk | Like in our case, where we want to have instances "evenly" distributed across AZs even when clients requested nothing | |
| 15:01:32 | noonedeadpunk | But, they will indeed be pinned to this AZ | |
| 15:03:08 | noonedeadpunk | But I also kinda wonder, if the output from the spec should be shown to everyone. As a user I will be also very confused if for some reasone these 2 will differ | |
| 15:03:50 | noonedeadpunk | While I totally get why I'd love to monitor that without doing DB queries on my own | |
| 15:04:28 | bauzas | noonedeadpunk: we have some customers that wonder why they can't move their instances to something else | |
| 15:05:14 | bauzas | endusers don't really know about that, but they can see that their instance is pinned or not | |
| 15:05:49 | bauzas | but agreed on the fact operators would want to have a specific policy for this parameter | |
| 15:05:52 | noonedeadpunk | Hm, does scheduler hint for specific compute may also result in instance being pinned to it? I guess not? | |
| 15:06:01 | noonedeadpunk | As it's hint after all... | |
| 15:06:08 | bauzas | it shouldn't | |
| 15:06:24 | bauzas | we only pin on three facts : | |
| 15:06:32 | bauzas | - the user requested an AZ | |
| 15:06:48 | bauzas | - the operator defaulted instances to an AZ (per nova-api service) | |
| 15:07:13 | bauzas | - the instance is attached to a volume that *already* uses an AZ | |
| 15:07:42 | bauzas | I don't see any other conditions where we would pin | |
| 15:08:04 | noonedeadpunk | I think `pinned_availablity_zone` makes sense indeed. As "attached" as Sean mentioned can also be slightly confusing | |
| 15:08:08 | bauzas | except of course if some operator changed the RequestSpec value directly :p | |
| 15:08:27 | bauzas | noonedeadpunk: could you then add a comment in the spec ? | |
| 15:10:01 | bauzas | noonedeadpunk: fwiw, /me going to look at your own spec :) | |
| 16:12:10 | sean-k-mooney | ykarel: https://review.opendev.org/c/openstack/tempest/+/905130 is the fix for what i mentioned | |
| 16:12:19 | sean-k-mooney | or at least my first attempt of a fix | |
| 16:15:30 | bauzas | noonedeadpunk: https://review.opendev.org/c/openstack/nova-specs/+/900296 mostly because you haven't written the work items and the spec doesn't have any owner | |
| 16:15:46 | bauzas | will you have time to work on it this cycle ? | |
| 16:15:53 | bauzas | you or someone else you know ? | |
| 16:20:40 | noonedeadpunk | Well. Yes, I was planning to work on that, though I initially also expected to have slightly more time for it... | |
| 16:20:55 | bauzas | shouldn't be a large feature | |
| 16:21:12 | bauzas | add a new weigher should be an easy peasy | |
| 16:21:19 | noonedeadpunk | Yeah, that's true. | |
| 16:21:38 | bauzas | the most large patch would be adding the policy and the rule, with all files to touch due to the new microversion | |
| 16:21:48 | bauzas | most largest* | |
| 16:22:07 | bauzas | but I can help you on that | |
| 16:22:10 | noonedeadpunk | and caching part you wrote concerns me as well a bit | |
| 16:22:41 | noonedeadpunk | as will need get myself aware of how that's done today (never touched this part of code) | |
| 16:28:09 | noonedeadpunk | bauzas: about policies - what policies you have in mind? | |
| 16:28:30 | noonedeadpunk | as I was thinking that existing `os_compute_api:os-server-groups` would cover this? | |
| 16:28:38 | bauzas | noonedeadpunk: well, I wrote "cache it" but actually, it shouldn't be a cache | |
| 16:29:09 | noonedeadpunk | it's jsut get AZs to a var and then iterate over filters kinda? | |
| 16:29:16 | bauzas | yeah exactly | |
| 16:29:35 | bauzas | but the fact is that the weigher only knows about a few things | |
| 16:29:35 | noonedeadpunk | gotcha | |
| 16:29:46 | bauzas | https://github.com/openstack/nova/blob/master/nova/scheduler/weights/affinity.py#L39 | |
| 16:30:03 | bauzas | so you would need to pass the list of azs into some object- | |
| 16:30:55 | noonedeadpunk | well, request_spec sounds like what is needed? | |
| 16:31:03 | noonedeadpunk | ah, ok, list of available ones | |
| 16:31:41 | bauzas | req_spec is a formal oslo object | |
| 16:31:59 | bauzas | I wouldn't recommend to use it, but that's your choice | |
| 16:32:15 | bauzas | I just want to not have a oslo.versioned field for that | |
| 16:32:33 | bauzas | some internal attribute for this object would work for it | |
| 16:32:38 | bauzas | for me* | |