| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-29 | |||
| 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 | |
| 14:15:52 | gmann | ok | |
| 14:16:18 | gibi | gmann: we had this fix https://review.opendev.org/c/openstack/tempest/+/786465 | |
| 14:17:00 | gmann | gibi: ohk, seems it still failing. I will check logs after qa meeting | |
| 14:17:43 | gibi | it is stil the parent port that remains DOWN | |
| 14:17:54 | gmann | ohk | |
| 14:29:56 | stephenfin | viks_: Last I checked, Apple's licensing only supports MacOS on Apple hardware. Maybe you could provision Mac Minis or Mac Pros using Ironic but using VMs (via nova) don't seem likely | |
| 14:29:58 | stephenfin | *doesn't | |
| 14:34:03 | sean-k-mooney | viks_: no not really you could try using uefi and q35 | |
| 14:34:27 | sean-k-mooney | but baskcialy macos has some specifc hardware requirement that i dont think qemu can fully emulate | |
| 14:35:19 | sean-k-mooney | i have seen peopel hack around it in the past by modifying the apple bootloader/kernel but its not fully supportred in qemu/libvirt and its not allowed by apples licening as stephen point out i belive | |
| 14:36:06 | sean-k-mooney | stephenfin: you could run vms via nova on a mac mini but those vms would have to be windows or linux | |
| 14:36:31 | sean-k-mooney | apple has a hypervior interface in the os which qemu can use | |
| 14:37:15 | sean-k-mooney | and libvirt can manage it but i dont think we can use kvm so enable the native support currenlty via libvirt | |
| 14:38:39 | viks_ | stephenfin: sean-k-mooney ok thanks | |
| 14:42:24 | kashyap | viks_: sean-k-mooney: Hardware accel with QEMU + MacOS works with "-accel hvf"; I recently checked it w/ QEMU upstream | |
| 14:42:47 | kashyap | viks_: I was told these instructions from Brew work in general: https://wiki.qemu.org/Hosts/Mac | |
| 14:43:52 | kashyap | viks_: Oh, wait - IIUC, you want to run MacOS as a guest on x86. | |
| 14:46:18 | viks_ | kashyap: ok... thanks... basically i wanted to see if i can provision mac os, either on kvm or baremetal ... and if is there any POC /doc related to it in openstack | |