| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-29 | |||
| 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 | |
| 14:46:59 | kashyap | (Nod) Upstream QEMU has MacOS as part of its CI | |
| 14:47:02 | kashyap | But no robust testing, IIUC | |
| 14:48:25 | viks_ | kashyap: ok... thanks | |
| 15:08:04 | sean-k-mooney | kashyap: yep and they also recently added apple silicon support | |
| 15:10:09 | stephenfin | slaweq: That failure on https://review.opendev.org/c/openstack/nova/+/798635 looks unrelated. Looks like https://review.opendev.org/c/openstack/neutron/+/798634/ did the trick. Thanks! | |
| 15:10:32 | slaweq | stephenfin thx for info :) | |
| 15:12:26 | sean-k-mooney | slaweq: that should not have broken things by the way but yes https://review.opendev.org/c/openstack/neutron/+/798634/ should fix it | |
| 15:13:00 | sean-k-mooney | slaweq: we still technically support live migration without binding-extended since we cannot yet make that a mandaory requriemetn on the neutron side | |
| 15:13:37 | sean-k-mooney | slaweq: it would be really nice to make it mandatory going forward but we need neutron to provide a way to do that | |
| 15:14:42 | slaweq | sean-k-mooney You mean to somehow force it on all plugins/drivers to support it, right? | |
| 15:15:19 | sean-k-mooney | slaweq: yes we need a way to intoduce mandatory extesions or move some of the current ones to be core extentions | |
| 15:15:32 | sean-k-mooney | so that we can stop supporting nuetorn backends that dont support it | |
| 15:15:49 | slaweq | yeah, that would be good thing | |
| 15:15:54 | sean-k-mooney | this would require contrail to finally add support for it | |
| 15:16:21 | slaweq | maybe this could be good topic for cross project session on the next PTG? :) | |
| 15:16:40 | sean-k-mooney | i have for the last 3-4 ptgs already | |
| 15:16:55 | sean-k-mooney | but i can i ask for this every time | |
| 15:17:45 | sean-k-mooney | we would basically just have to agree a process for graduation of extnsions to the core api | |
| 15:18:24 | sean-k-mooney | then for Y declare the following set will be added | |
| 15:18:45 | sean-k-mooney | basically give one upstream cycle at a minium to ensure all backend support the new ones | |
| 15:19:22 | sean-k-mooney | then nova could drop support in say Z and issue deprecation warnings in Y when the required exttion is not found | |
| 15:19:22 | slaweq | the problem is that we will be loud about it in the community | |
| 15:19:33 | slaweq | and finally someone will still miss announcement and will complain :) | |
| 15:19:59 | slaweq | maybe You could propose some initial draft of spec so we can discuss it there? | |
| 15:19:59 | sean-k-mooney | well we acidentally drop support for live migratrion without binding extened | |
| 15:20:11 | sean-k-mooney | and it took 14 months or so for peopel to complain | |
| 15:20:29 | sean-k-mooney | so yes they will but maybe not promptly | |
| 15:20:42 | sean-k-mooney | slaweq: sure is can propsose something | |
| 15:20:52 | slaweq | ++ thx | |
| 15:21:06 | slaweq | I will then ensure that neutron team will review it :) | |
| 15:21:19 | sean-k-mooney | do ye have a Y or backloag folder. i can propsoe it against xena but i dont really expect us to do anything concret this cycle | |
| 15:21:40 | sean-k-mooney | well other them maybe agree the driection | |
| 15:22:09 | sean-k-mooney | slaweq: by the way when is the neutron team meeting have you discussed the os-vif per-port bridge topic | |
| 15:22:22 | sean-k-mooney | slaweq: ill be brining that up in the nova meeeting later | |
| 15:22:36 | slaweq | we had that meeting 1h ago | |
| 15:22:47 | slaweq | and ralonsoh raised that issue | |
| 15:22:53 | slaweq | he will follow up with spec for that too | |
| 15:23:07 | sean-k-mooney | ack ok i can sync with him | |
| 15:23:15 | slaweq | ++ | |
| 15:25:15 | sean-k-mooney | has that been annouched | |
| 15:29:32 | kashyap | bauzas: Yeah; it sucks; but at least we see some "light at the end of the tunnel" and are not stuck in long virus waves. | |
| 15:30:05 | bauzas | sean-k-mooney: yup, one hour ago | |
| 15:30:26 | bauzas | kashyap: I understand the reasoning behind the decision but this hurts | |
| 15:30:55 | bauzas | I can just hope all the contributors could be vaccinated sooner than later so we could just ask them some kind of passport to travel | |
| 15:34:17 | bauzas | gibi: another thought, I need to leave by 6:15pm our time | |