Earlier  
Posted Nick Remark
#openstack-nova - 2021-06-07
16:24:18 artom An item for next PTG, perhaps
16:26:20 priteau Yeah that would be good
16:28:01 priteau I've proposed a spec for blazar to implement preemptibles, because in the context of using reservations it can be done without changes to nova
16:30:52 priteau That's the one linked by bauzas earlier: https://specs.openstack.org/openstack/blazar-specs/specs/ussuri/blazar-preemptible-instances.html
16:31:19 artom priteau, if that's the way it moves forward, RH would still have to productize Blazaar...
16:31:50 artom priteau, but good to know there would be no new code for us (RH) to write
16:31:53 priteau Yeah I am not saying this is a full solution for you ;)
16:32:11 artom Despite our millions, we're surprisingly people-strapped :P
16:32:30 artom Just getting Designate up and running was a more than year-long thing.
17:20:05 opendevreview Lee Yarwood proposed openstack/nova master: libvirt: Set driver_iommu when attaching virtio devices to SEV instance https://review.opendev.org/c/openstack/nova/+/794639
17:31:45 opendevreview Lee Yarwood proposed openstack/nova master: libvirt: Set driver_iommu when attaching virtio devices to SEV instance https://review.opendev.org/c/openstack/nova/+/794639
17:42:35 opendevreview Merged openstack/nova stable/wallaby: zuul: Replace grenade and nova-grenade-multinode with grenade-multinode https://review.opendev.org/c/openstack/nova/+/794345
17:57:34 opendevreview Ade Lee proposed openstack/nova master: Add check job for FIPS https://review.opendev.org/c/openstack/nova/+/790519
20:17:16 opendevreview melanie witt proposed openstack/nova stable/victoria: Honor [neutron]http_retries in the manual client https://review.opendev.org/c/openstack/nova/+/795175
20:19:39 opendevreview melanie witt proposed openstack/nova stable/ussuri: Honor [neutron]http_retries in the manual client https://review.opendev.org/c/openstack/nova/+/795176
20:21:05 opendevreview melanie witt proposed openstack/nova stable/train: Honor [neutron]http_retries in the manual client https://review.opendev.org/c/openstack/nova/+/795177
20:25:20 melwitt dansmith: if you fancy unblocking the stable/victoria gate https://review.opendev.org/c/openstack/nova/+/794674
20:43:57 opendevreview Vlad Gusev proposed openstack/nova stable/stein: Honor [neutron]http_retries in the manual client https://review.opendev.org/c/openstack/nova/+/795138
21:07:23 dansmith melwitt: and what if I like it broken?
21:08:12 melwitt dansmith: then you get the angry eyebrows >:|
21:08:32 dansmith ...which are more scary than a blocked gate, so... okay
21:09:18 melwitt or the look of disapproval ಠ_ಠ
21:09:20 melwitt :)
21:10:06 dansmith oh god, my childhood all over again
21:10:18 melwitt 😂
#openstack-nova - 2021-06-08
00:27:46 opendevreview Vlad Gusev proposed openstack/nova stable/stein: Honor [neutron]http_retries in the manual client https://review.opendev.org/c/openstack/nova/+/795138
07:27:16 opendevreview Yongli He proposed openstack/nova master: Smartnic support - cyborg drive https://review.opendev.org/c/openstack/nova/+/771362
07:27:20 opendevreview Yongli He proposed openstack/nova master: smartnic support - new vnic type https://review.opendev.org/c/openstack/nova/+/771363
07:27:28 opendevreview Yongli He proposed openstack/nova master: smartnic support https://review.opendev.org/c/openstack/nova/+/758944
07:27:38 opendevreview Yongli He proposed openstack/nova master: smartnic support - reject server move and suspend https://review.opendev.org/c/openstack/nova/+/779913
07:27:45 opendevreview Yongli He proposed openstack/nova master: smartnic support - functional tests https://review.opendev.org/c/openstack/nova/+/780147
09:04:19 slaweq hi nova team
09:04:34 slaweq in one of neutron jobs I have errors in nova-compute, like https://df08b3f27c09a85d3fe8-f65209ceca8d59b8b2f1e727ebf5e4dd.ssl.cf2.rackcdn.com/periodic/opendev.org/openstack/neutron/master/devstack-tobiko-faults-centos/d402aac/compute1/logs/screen-n-cpu.txt
09:04:47 slaweq do You maybe know what can be the reason of such issue?
09:04:55 slaweq I have virt_type=qemu set there
09:05:01 slaweq and cpu_mode=None
09:31:00 lyarwood stephenfin: morning, if you get a chance today can you hit https://review.opendev.org/c/openstack/nova/+/794639 please?
09:31:40 lyarwood https://review.opendev.org/q/topic:%2522bug/1905701%2522+status:open+branch:master is also ready for review if anyone has time
10:00:57 kashyap gibi: Hey, today's the upstream call, yeah? I'd like to bring this (fairly mechanical thing) up today - https://blueprints.launchpad.net/nova/+spec/add-bochs-display-device
10:02:06 kashyap gibi: WIP here: https://review.opendev.org/q/topic:%22bp%252Fadd-bochs-display-device%22+(status:open%20OR%20status:merged)
10:27:45 sean-k-mooney slaweq: it looks like that job is trying to enable sev es to be availe in the guest without kvm
10:28:10 sean-k-mooney libvirt.libvirtError: internal error: unknown feature amd-sev-es
10:29:07 slaweq sean-k-mooney yeah, but there is nothing like that configured in the job
10:29:18 slaweq and that's actually weird for me :)
10:29:57 slaweq sean-k-mooney I think we may be hitting https://bugzilla.redhat.com/show_bug.cgi?id=1961562 there
10:29:58 opendevmeet bugzilla.redhat.com bug 1961562 in libvirt "vm can not start with error as "internal error: unknown feature amd-sev-es"" [Urgent,Verified] - Assigned to phrdina
10:30:14 sean-k-mooney slaweq: ya its not a nova bug
10:30:21 slaweq but would be great if You could confirm that :)
10:30:37 sean-k-mooney we are not requesting it in the xml so this a libvirt /qemu issue on the amd host
10:31:01 sean-k-mooney ah ok
10:32:53 sean-k-mooney so that looks like the exact same issue
10:32:55 sean-k-mooney Error from libvirt when retrieving domain capabilities for arch i686 / virt_type qemu / machine_type q35: [Error Code 1]: internal error: unknown feature amd-sev-es {{(pid=75619) _add_to_domain_capabilities /opt/stack/nova/nova/virt/libvirt/host.py:982}}
10:33:40 sean-k-mooney slaweq: as a workaround you could likely define a cpu model that did not support sev-es
10:34:22 slaweq sean-k-mooney thx, I will try that
10:35:03 sean-k-mooney cpu_mode=custom cpu_model=EPYC-IBPB
10:35:12 sean-k-mooney in the libvirt section
10:35:48 sean-k-mooney cpu_mode=none in the libvirt driver on x86 is equvalent to cpu_mode=host-model
10:36:52 sean-k-mooney although it is actully generating <cpu match="exact"> with qemu instead of kvm
10:37:15 sean-k-mooney which i tought was the same as host-passthough not host-model since there is no model specified
10:37:53 slaweq ok, so setting cpu_mode=custom cpu_model=EPYC-IBPB in the job should helps to workaround that issue, correct?
10:41:05 sean-k-mooney yes i think so but only if we know that all the host support that
10:41:18 sean-k-mooney if we dont know that we have other options
10:42:29 sean-k-mooney we could go with cpu_model=kvm64 or proably Nehalem-IBRS
10:43:07 slaweq sean-k-mooney that job is running in the u/s ci so I can't be sure that all providers will support that EPYC-IBPB
10:43:10 sean-k-mooney cpu_model=Nehalem-IBRS while an intel plathform is very clouse to the new x86 featrel level that is being used to compile rhel 9 with
10:44:09 slaweq and also tests in that job don't need any advanced cpu features so I think that I would try with as much "generic" type as possible
10:44:11 sean-k-mooney slaweq: i would try cpu_model=Nehalem-IBRS then and if that dows not work try falling back to qemu64
10:44:29 slaweq sean-k-mooney ok, thx a lot
10:44:32 slaweq I will try that
10:44:46 kashyap slaweq: The EPYC-IBPB model will only work if ... obviously your host supports it
10:44:56 kashyap You can check it via `virsh cpu-models x86_64`
10:45:21 kashyap ("it" == supported models by your libvirt+QEMU)
10:45:47 slaweq kashyap I actually can't check it like that in the zuul ci jobs
10:45:47 sean-k-mooney kashyap: this is running on upshift which is hosted by vexhost using i would guess there new amd eypc zen2 servers
10:47:29 sean-k-mooney assuming they are all the same then they are second gen epyc cpus from 2 years ago but nehalem is ~8-11 years old so it should be emulatable on anything that is still in production today
10:47:43 kashyap I see
10:53:50 stephenfin lyarwood: took me a bit but +2 on https://review.opendev.org/c/openstack/nova/+/794639 now. sean-k-mooney might be interested if they've time
10:55:47 sean-k-mooney i can re review it now
10:56:50 stephenfin lyarwood: also, can you send an email to openstack-discuss RE: https://review.opendev.org/c/openstack/nova/+/794252. They're likely totally useless but we've always done it historically
10:57:04 sean-k-mooney stephenfin: well
10:57:12 sean-k-mooney for PCI passthrough attach, from '_attach_direct_passthrough_ports': not relevant since these clearly can't be virtio devices
10:57:17 sean-k-mooney they can
10:57:28 sean-k-mooney oh _attach_direct_passthrough_ports
10:57:50 stephenfin Really? That doesn't make much sense to me
10:57:58 sean-k-mooney i was going to say macvtap and vdpa sriov interface will be virtio
10:58:03 stephenfin Other types of "passthrough", sure
10:58:04 stephenfin Yeah
10:58:18 sean-k-mooney if that is just direct then ya
10:58:46 stephenfin Would be good to double check. I think it is but I might have missed something
10:59:27 sean-k-mooney im checking now but it shoudl be fine
10:59:45 stephenfin in other news, /me has a briar thorn stuck in his fingertip that he can't remove which is making typing extremely uncomfortable today :-D
10:59:53 sean-k-mooney attach_interface is the entrypoint that would handel all sriov attach anyway
11:00:14 sean-k-mooney ouch
11:01:13 sean-k-mooney stephenfin: so right now it should be ok https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4821-L4840
11:01:43 sean-k-mooney i have worked with prototype nics that expsoed virtio-net-pci devices as VFsd though in the past
11:08:23 sean-k-mooney with the caveat the i woudl silll like the sev atibetes fo the nices to be handeled in vif.py eventualy im +1 on that change
11:13:08 opendevreview Stephen Finucane proposed openstack/nova master: docs: Replace 'nova boot' with 'openstack server create' https://review.opendev.org/c/openstack/nova/+/794007
11:13:14 gibi kashyap: ack, I've added to the agenda
11:13:59 stephenfin gibi: lyarwood: if you've time this week, could I get your eyes on this follow-up series for the RPC 6.0 change from last cycle. bauzas is +2 on pretty much all of it now https://review.opendev.org/q/topic:"compute_rpc_6.0"+status:open
11:20:13 sean-k-mooney stephenfin: is that removing the proxy?

Earlier   Later