| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-29 | |||
| 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? | |
| 13:51:11 | kashyap | sean-k-mooney: Yep; noted, I'll give it go | |
| 13:52:31 | sean-k-mooney | kashyap: in general no. teh vm models should not change on hard reboot | |
| 13:52:37 | sean-k-mooney | it may or may not break guests | |
| 13:52:44 | sean-k-mooney | it really depens on if they have drivers | |
| 13:53:00 | sean-k-mooney | it should fall back to generic vga in this case | |
| 13:53:07 | sean-k-mooney | so it should work | |
| 13:53:19 | sean-k-mooney | but in general for other models it would nto be safe | |
| 13:53:22 | kashyap | sean-k-mooney: Right; preserving the guest ABI, etc. That's the reason also why libvirt doesn't gratuitously change things on cold reboot, though | |
| 13:53:30 | sean-k-mooney | e.g. disk bus | |
| 13:53:45 | kashyap | sean-k-mooney: Yep; the fallback to generic VGA should catch it. So I don't think there'd be any visible breakage | |
| 13:54:19 | sean-k-mooney | right so we really just need to see in this case if people are ok with the upgrade impact since its mitigated by generic vga | |
| 13:54:26 | sean-k-mooney | well provided your not useing rhel 6 | |
| 13:55:32 | sean-k-mooney | rhel 7 shoudl be fine but rhel 6 predates the intoduction of virtio-gpu and i do not belive they have the required kernel support even with the fallback but i coudl be miss remebering that | |
| 13:56:01 | sean-k-mooney | it may have been related to one of the other email treads i just rememebr there bing an issue with virtio and rhel 6 mentioned recently | |
| 13:57:21 | kashyap | sean-k-mooney: No worries about RHEL-6 - RHEL-6 is not supported by OSP | |
| 13:57:27 | sean-k-mooney | rhel6 went to els only phase on November 30, 2020 but els exits untile June 30, 2024 | |
| 13:57:33 | kashyap | Yes; am aware of the RHEL-6/CentOS 6 thing | |
| 13:57:40 | sean-k-mooney | kashyap: as a guest it is | |
| 13:58:12 | sean-k-mooney | altough ya it woudl need els | |
| 13:58:20 | kashyap | Yep; | |
| 13:58:25 | sean-k-mooney | anyway that is the onel really issue i see | |
| 14:00:00 | sean-k-mooney | gibi: not that i want to reopen the owner_triat conversation but part of the reason for intoducing them was to give each service at least 1 unique tratit that only they will use | |
| 14:00:51 | sean-k-mooney | i do agree that that is the main different between nova<>cinder and nova<>cyborg | |
| 14:08:50 | gibi | for me owner means the RP the trait is on cannot be touched by any other placement client, but we simply cannot enforce that semantic in placement | |
| 14:09:07 | gibi | and as I said there are many undefined edges of the semantic itself | |
| 14:11:15 | viks_ | Hi, is there any way we can provision MAC os? | |
| 14:11:29 | viks_ | using openstack nova? | |
| 14:12:21 | gmann | lyarwood: gibi is this know issue - test_live_migration_with_trunk failing consistently https://zuul.opendev.org/t/openstack/build/94d92ea104734ba49f6c93e17a91e3f7/log/job-output.txt#63963 | |
| 14:15:35 | gibi | gmann: we have port status issue before | |
| 14:15:39 | gibi | gmann: let me find it | |