| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-01-10 | |||
| 12:46:38 | noonedeadpunk | here we go ^ | |
| 12:49:11 | sean-k-mooney | +2 | |
| 12:49:12 | sean-k-mooney | thanks | |
| 12:49:22 | sean-k-mooney | have you started on the implementaion | |
| 12:50:20 | sean-k-mooney | can you use the cross-az-instance-scheduling gerrit topic when working on that | |
| 12:50:30 | sean-k-mooney | to keep the spec and code all on the same topic | |
| 12:51:48 | noonedeadpunk | I have not yet (as was not sure if lueprint will land or not, and that was kinda requirement from here to start working on it) | |
| 12:52:05 | noonedeadpunk | and yes, sure I can use the topic you've mentioned | |
| 13:32:41 | bauzas | sean-k-mooney: yeah today I'm looking at specs | |
| 13:39:43 | dvo-plv | sean-k-mooney, Hello | |
| 13:44:03 | sean-k-mooney | dvo-plv: o/ | |
| 13:44:11 | dvo-plv | I asked a question above regarding correct appropriate with spec file changes, when it was merged | |
| 13:44:20 | dvo-plv | Could you pelase advice me something | |
| 13:47:05 | sean-k-mooney | sorry i didnt see that question can you restate it | |
| 13:47:19 | sean-k-mooney | are you asking when is it ok to update a merges spec | |
| 13:47:32 | sean-k-mooney | to reflect change based on the review of the code | |
| 13:48:15 | sean-k-mooney | if so, while we avoid chanign things during review in general we allwo reconsiling the spec based on those changes at any time | |
| 13:48:54 | sean-k-mooney | we would prefer the spec to be correct since it is use as documetation by both us and operator so you can propose a patch to the spec repo to fix a spec even after spec freeze | |
| 14:04:36 | bauzas | sean-k-mooney: fwiw, even if I agree with the usecase (listing the pinned AZ), I -1d https://review.opendev.org/c/openstack/nova-specs/+/904368 because of the difference between 'I requested a AZ' and 'my instance is pinned' | |
| 14:06:13 | bauzas | ratailor: ^ see my comment above ^ | |
| 14:25:38 | sean-k-mooney | bauzas: responed | |
| 14:25:49 | sean-k-mooney | your not wrong altough i dont entirly agree with all your coments | |
| 14:26:23 | sean-k-mooney | i would not be opposed to the spec if your comment were adressed however | |
| 14:26:54 | sean-k-mooney | you and i are readign requested to have 2 diffent meanings | |
| 14:27:15 | sean-k-mooney | for me an az is requested if the az filed in the request_spec is populated for any reason | |
| 14:27:26 | sean-k-mooney | for you its requested only if it was in the http post | |
| 14:27:43 | sean-k-mooney | thats disconnect between my reading and your reading of the spec | |
| 14:28:33 | noonedeadpunk | I'd actually vote for taking AZ from request_spec regardless of how it's appeared there | |
| 14:28:36 | sean-k-mooney | im ok with using your interperation and updating the spec to reflect that but form the persptice of the schduelr its requested if there is a value in the request spec | |
| 14:28:54 | bauzas | sean-k-mooney: I provided an alternative name for the API field | |
| 14:29:02 | noonedeadpunk | As actually I assume that what matters at the end... | |
| 14:29:05 | bauzas | 'attached_availability_zone' | |
| 14:29:17 | sean-k-mooney | i dont like attached | |
| 14:29:34 | sean-k-mooney | you also sugggested pinned_availablity_zone | |
| 14:29:39 | bauzas | we already have 'cross_az_attach' option, hence my name | |
| 14:29:52 | sean-k-mooney | attach in that context is refering to the volume not the az | |
| 14:30:02 | bauzas | possibly yeah | |
| 14:30:24 | sean-k-mooney | so pinned_aviableity_zone or required_avilablity_zone are all fine | |
| 14:30:31 | bauzas | the fact is that I want my user to understand that the instance is only using this AZ without looking at the api docs | |
| 14:30:50 | sean-k-mooney | noonedeadpunk: form an operator perspective what would you find more intuitive | |
| 14:30:51 | bauzas | I'm not fine with 'requested_az' for the reason I explained | |
| 14:31:17 | sean-k-mooney | right but i actully think that is the most correct form for the reasons i explaied :) | |
| 14:31:27 | bauzas | the fact that neither the operator nor the user could request this instance to be pinned while the instance would still be pinned | |
| 14:31:31 | sean-k-mooney | but i dont really care too much what the field name is | |
| 14:31:47 | sean-k-mooney | bauzas: right but its part of the requst_spec | |
| 14:31:58 | sean-k-mooney | there for the az was requested | |
| 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 | |