| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-29 | |||
| 13:10:34 | gibi | bauzas: ack, this works for me | |
| 13:10:41 | sean-k-mooney | the alternitive being stick to the az that host is in, reject the request or keep the current behavior | |
| 13:10:57 | sean-k-mooney | i think im ok with what bauzas is suggesting too | |
| 13:11:14 | bauzas | and like I said, if the operator wants to land on host and stick to foo, they can say --host host and --az foo | |
| 13:11:27 | bauzas | then, they'll get NoValidHosts | |
| 13:11:47 | bauzas | sean-k-mooney: I don't like the alternative as I don't wanna verify the AZ by the API | |
| 13:11:58 | bauzas | since the AZFilter can be disabled | |
| 13:12:12 | sean-k-mooney | its not related to the az filter | |
| 13:12:14 | bauzas | and I know some ops that use forced_hosts hack but don't run AZFilter | |
| 13:12:31 | sean-k-mooney | instance hav az without that | |
| 13:12:46 | bauzas | we only enforce AZs by the filter | |
| 13:12:56 | bauzas | or by placement | |
| 13:13:01 | sean-k-mooney | no we also suport^ | |
| 13:13:03 | bauzas | (if the prefilter is enabled) | |
| 13:13:12 | sean-k-mooney | yep and you can disable both | |
| 13:13:16 | bauzas | correct | |
| 13:13:29 | bauzas | so, you can technically use the forced_hosts hack without using AZs | |
| 13:13:30 | sean-k-mooney | although the filter should get deprecated this cycle and removed next cycle | |
| 13:13:38 | bauzas | whatever | |
| 13:13:42 | sean-k-mooney | but the prefilter will still be configurable | |
| 13:13:47 | bauzas | we'll continue to verify AZs by the scheduler | |
| 13:13:50 | sean-k-mooney | although on by default | |
| 13:13:57 | bauzas | like the AZFilter ;) | |
| 13:14:06 | sean-k-mooney | right although we could do in the api instead | |
| 13:14:09 | bauzas | no | |
| 13:14:15 | bauzas | it's a breaking change | |
| 13:14:18 | sean-k-mooney | its a viald althernitive | |
| 13:14:31 | sean-k-mooney | bauzas: not if its configurable although yes config driven api behavior is bad | |
| 13:14:45 | sean-k-mooney | although that is effectivly what we do with the filter | |
| 13:14:50 | bauzas | we said a couple of times to *not* verify the filters by the api service | |
| 13:15:02 | bauzas | the api service needs to be scheduler agnostic | |
| 13:15:19 | sean-k-mooney | this is not really verifying the filter | |
| 13:15:26 | sean-k-mooney | its verifying if the request is valid | |
| 13:15:32 | sean-k-mooney | anyway | |
| 13:15:36 | bauzas | it's enforcing AZs on the API side while you could have disabled it | |
| 13:15:45 | bauzas | and I have serious concerns about it | |
| 13:16:00 | bauzas | but yeah, I think we have a plan | |
| 13:16:02 | sean-k-mooney | well long term i would like to remove the ablity to diable az filtering | |
| 13:16:12 | opendevreview | Merged openstack/nova master: Fix error '404 Not Found' https://review.opendev.org/c/openstack/nova/+/797233 | |
| 13:16:13 | sean-k-mooney | and by long term i mean in Z | |
| 13:16:18 | bauzas | sean-k-mooney: you'll release the operator's fury | |
| 13:16:33 | sean-k-mooney | why by default everything will be in one az | |
| 13:16:39 | bauzas | AZs *have to* be optional | |
| 13:16:41 | sean-k-mooney | it wont have any impact on them | |
| 13:16:54 | sean-k-mooney | everythign is in the nova az by default | |
| 13:17:05 | sean-k-mooney | well unles you rename the default az | |
| 13:17:06 | bauzas | sean-k-mooney: again, it's not a matter of AZs topology | |
| 13:17:18 | bauzas | sean-k-mooney: it's about the contract the user is signing off when booting | |
| 13:17:25 | sean-k-mooney | yes | |
| 13:17:35 | bauzas | either they decide to stick to an AZ or to be AZ-agnostic | |
| 13:17:38 | sean-k-mooney | i did not say you had to request it | |
| 13:17:44 | bauzas | having one big AZ won't help | |
| 13:17:52 | sean-k-mooney | i jus said we shoudl always report and filter based on it if present | |
| 13:18:09 | sean-k-mooney | if there is no az request the placement query woudl be identical | |
| 13:18:52 | sean-k-mooney | bauzas: what i would like to see is the request spec az remains as None by default | |
| 13:19:10 | sean-k-mooney | but that we would alway check az if requested with the placment query | |
| 13:19:20 | bauzas | sean-k-mooney: some operators make use of schedule_default_az with different values on the API services | |
| 13:19:36 | sean-k-mooney | yep that would still work | |
| 13:19:42 | bauzas | so they round-robin their instances between AZs by the number of workers | |
| 13:19:47 | sean-k-mooney | since that would populate the requestspec | |
| 13:20:14 | sean-k-mooney | i would just like to remove the az filer in Y and remove disabling the placment query in Z | |
| 13:20:18 | sean-k-mooney | no other changes | |
| 13:20:22 | bauzas | sean-k-mooney: that's a breaking change, right? | |
| 13:20:28 | sean-k-mooney | bauzas: it should not be no | |
| 13:20:45 | bauzas | sean-k-mooney: because atm, users can ask for AZs and silently move between AZs | |
| 13:20:47 | sean-k-mooney | unless they are forcing to host with a wrong az | |
| 13:20:52 | bauzas | so, at least a microversion | |
| 13:21:21 | sean-k-mooney | how can they move between az if they asked for one | |
| 13:21:42 | sean-k-mooney | with what a forced migration? | |
| 13:22:40 | sean-k-mooney | the requst spec az wont get updated so if you asked for one at boot you will always stay inside that az unless the admin forces a migration | |
| 13:23:42 | sean-k-mooney | bauzas: anyway i think im ok with your "set request spec to None" when you do the az hack proposal | |
| 13:24:49 | sean-k-mooney | but i think we evenuatlly could validate it in the api if we wanted too and as i said i think by z we shoudl just always add teh az if present in the quest spec to the placment query | |
| 13:25:07 | sean-k-mooney | modulo perhapse if you are using an older microverion for a forced migration | |
| 13:26:05 | sean-k-mooney | althogh im not sure about the last part, e.g. shoudl we continue to support forced migrations that break az affinity. that not todays problem however | |
| 13:32:17 | opendevreview | Kashyap Chamarthy proposed openstack/nova master: libvirt: Switch the default video model from 'cirrus' to 'virtio' https://review.opendev.org/c/openstack/nova/+/798680 | |
| 13:42:04 | opendevreview | Kashyap Chamarthy proposed openstack/nova master: libvirt: Switch the default video model from 'cirrus' to 'virtio' https://review.opendev.org/c/openstack/nova/+/798680 | |
| 13:46:08 | sean-k-mooney | kashyap: you cant do ^ this cycle | |
| 13:46:22 | kashyap | sean-k-mooney: Too late? | |
| 13:46:34 | kashyap | sean-k-mooney: You mean a deprecation cycle? | |
| 13:46:36 | sean-k-mooney | no you need to recored the currnt video model this cycle | |
| 13:46:41 | kashyap | Ohh, right; darn | |
| 13:46:50 | sean-k-mooney | then and only then can we change the default | |
| 13:47:06 | sean-k-mooney | so you can write the patch and we can merge it early Y | |
| 13:47:07 | kashyap | There's that part...where are we w.r.t that? I know Lee did the work for machine types | |
| 13:47:29 | sean-k-mooney | currently we have not started on it so it | |
| 13:47:35 | sean-k-mooney | its not really hard to do | |
| 13:47:36 | kashyap | sean-k-mooney: Yeah; fair enough, good point. So the blueprint is only for Y? | |
| 13:48:07 | sean-k-mooney | yes i think so but you coudl bring it up in the team meeting later | |
| 13:48:21 | kashyap | Nod; I'll mark it as -W for now | |
| 13:48:23 | sean-k-mooney | currntly the upgrade impact woudl be the dispaly woudl change on hard reboot | |
| 13:48:53 | sean-k-mooney | if people were ok with with we coudl proceed but i expect this would break some peopele hence the need to record it | |
| 13:49:03 | sean-k-mooney | downstream we could backport the recording patch | |
| 13:49:10 | sean-k-mooney | but upstream i dont think that woudl be accpeted | |
| 13:49:51 | sean-k-mooney | e.g. downstream we could start recordign the video model in 16.2/train if we rally wanted or in 17/wallaby | |
| 13:49:54 | kashyap | sean-k-mooney: That is record it in system_metadata, yeah? | |
| 13:50:02 | sean-k-mooney | yes | |
| 13:50:24 | kashyap | Nod. | |
| 13:50:46 | sean-k-mooney | you should be able to copy paste part of lee's machine type patch | |
| 13:50:54 | sean-k-mooney | if you want to give it a try | |
| 13:50:58 | kashyap | sean-k-mooney: On hard reboot - display changing shold be acceptable, no? | |