| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-10 | |||
| 14:32:04 | sean-k-mooney | it does not makter who requeteded it | |
| 14:32:12 | bauzas | sean-k-mooney: well, some enduser doesn't know the internals | |
| 14:32:28 | sean-k-mooney | yep which is why im interested in noonedeadpunk input | |
| 14:32:35 | sean-k-mooney | im fine with using a diffent name | |
| 14:32:51 | bauzas | noonedeadpunk: tell me a better name and I +2 your own spec :p | |
| 14:32:53 | bauzas | (jk) | |
| 14:32:55 | sean-k-mooney | so if you think somethign else is better that is ok with me althoug lets avoid attach | |
| 14:33:14 | sean-k-mooney | bauzas: this is now noonedeadpunk spec | |
| 14:33:19 | sean-k-mooney | theres is the other one | |
| 14:33:22 | bauzas | sean-k-mooney: I'm quite conservative on AZs given it's an enduser param | |
| 14:33:45 | bauzas | and most OVH endusers (for example) don't know a single bit of the nova internals | |
| 14:34:07 | sean-k-mooney | well even those that do disagree on how az should be used | |
| 14:34:10 | bauzas | sean-k-mooney: yeah I know, we're speaking of ratailor's spec | |
| 14:34:18 | sean-k-mooney | i for one have no issue with explcitly requesting the nova az | |
| 14:34:31 | sean-k-mooney | i know why you dont like that | |
| 14:34:39 | sean-k-mooney | but to me that is perfectly valid | |
| 14:34:58 | sean-k-mooney | and i know of cloud that have configured default_schedule_zone=nova | |
| 14:35:15 | sean-k-mooney | thats a tangent | |
| 14:35:22 | bauzas | that's a terrible thing | |
| 14:35:32 | bauzas | and we documented that | |
| 14:35:47 | sean-k-mooney | bauzas: right but horizon default to nova and i belive it always puts it in the request | |
| 14:35:54 | bauzas | NOOOOOOOOOOOOOOOOOOOOOOOOOOO | |
| 14:36:13 | bauzas | are you joking ? | |
| 14:36:17 | sean-k-mooney | i know that horizon use to alwasy require an az in the drop down | |
| 14:36:31 | sean-k-mooney | and if nova was the only one in the list you had no other choice | |
| 14:36:34 | bauzas | that's an horizon bug then | |
| 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 | noonedeadpunk: default_schedule_zone you mean . | |
| 14:40:13 | bauzas | ? | |
| 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 ? | |