Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-06-29
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 slaweq the problem is that we will be loud about it in the community
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:33 slaweq and finally someone will still miss announcement and will complain :)
15:19:59 sean-k-mooney well we acidentally drop support for live migratrion without binding extened
15:19:59 slaweq maybe You could propose some initial draft of spec so we can discuss it there?
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
15:34:42 bauzas if we can do a quick meeting, that'd be lovely
15:34:52 gibi bauzas: I will try to be quick
15:34:59 gibi and thanks for the headsup
15:36:23 sean-k-mooney i have one networking topic to bring up in open discuss but apparently its going to be a spec now instead of a bug so i guess it will be an fyi.
15:36:40 sean-k-mooney and review the spec
15:37:36 sean-k-mooney slaweq: by the way we had planned to treat it as a bug because i didn tno really want to do a downstream only backport of this though we can disucss later
15:46:20 gibi sean-k-mooney: ack
15:54:58 gibi nova meeting starts in 5 minutes here in the channel
15:55:23 opendevreview Merged openstack/nova stable/ussuri: Error anti-affinity violation on migrations https://review.opendev.org/c/openstack/nova/+/796719
15:59:00 opendevreview Stephen Finucane proposed openstack/nova master: scheduler: Remove 'USES_ALLOCATION_CANDIDATES' https://review.opendev.org/c/openstack/nova/+/773640
15:59:01 opendevreview Stephen Finucane proposed openstack/nova master: scheduler: 'USES_ALLOCATION_CANDIDATES' removal cleanup https://review.opendev.org/c/openstack/nova/+/797513
15:59:01 opendevreview Stephen Finucane proposed openstack/nova master: scheduler: Remove 'hosts_up' https://review.opendev.org/c/openstack/nova/+/773641
15:59:02 opendevreview Stephen Finucane proposed openstack/nova master: trivial: Remove FakeScheduler (for realz) https://review.opendev.org/c/openstack/nova/+/773642
15:59:02 opendevreview Stephen Finucane proposed openstack/nova master: scheduler: Merge 'FilterScheduler' into base class https://review.opendev.org/c/openstack/nova/+/773643
15:59:03 opendevreview Stephen Finucane proposed openstack/nova master: docs: Drop references to non-filter scheduler drivers https://review.opendev.org/c/openstack/nova/+/773645
15:59:03 opendevreview Stephen Finucane proposed openstack/nova master: scheduler: Merge driver into manager https://review.opendev.org/c/openstack/nova/+/773644
15:59:04 opendevreview Stephen Finucane proposed openstack/nova master: tests: Merge 'test_utils', 'test_scheduler_utils' https://review.opendev.org/c/openstack/nova/+/773646
15:59:04 opendevreview Stephen Finucane proposed openstack/nova master: conf: Remove deprecated aliases https://review.opendev.org/c/openstack/nova/+/773647

Earlier   Later