Earlier  
Posted Nick Remark
#openstack-nova - 2019-06-20
14:53:42 aspiers efried: OK. Totally open to suggestions for how to fix that
14:53:44 efried aspiers: You can put the os-traits bump in whatever patch first needs it. That's fine.
14:53:58 stephenfin jangutter, sean-k-mooney, ralonsoh: I've royally confused myself again (every damn time) - either of you care to remind me of the difference between VIF_TYPE_foo and VNIC_TYPE_foo?
14:54:24 efried aspiers: I'm saying that exposing the inventory is a nice master switch, because without it, there's zero expectation of anything else working.
14:54:26 aspiers efried: o-r-c not o-t, but yeah sure, I can split the o-r-c patch in two
14:54:35 stephenfin I think one refers to the backend that handles the VIF, while the other determines how it's actually attached to the instance. Right?
14:54:44 aspiers efried: wfm
14:55:11 jangutter stephenfin: VNIC_TYPE can in theory be set by the user, where VIF type is behind the scenes.
14:55:11 efried aspiers: As far as I'm concerned, we can *always* bump ot and orc to latest. (In other projects we've implemented canary tests that will fail as soon as a new release comes through upper-constraints.)
14:55:25 aspiers efried: yup, makes sense
14:55:43 efried aspiers: So for my money, you could do that in its own patch on the bottom, and not even have to tag it against this blueprint.
14:55:53 jangutter stephenfin: VNIC is an _attribute_ of the VIF.
14:56:43 Sundar sean-k-mooney, mriedem, gibi, johnthetubaguy: There has been further discussion on Line 276 of https://review.opendev.org/#/c/603955/14. That seems to be the sole point to address before this spec is merged. Please take a look. Thanks.
14:57:09 stephenfin jangutter: So in theory any VIF type could use one of the...six VNIC types we provide?
14:57:45 jangutter stephenfin: there are two checks I think. Neutron has to allow it, and Nova has to translate it right from Neutron.
14:58:23 stephenfin Yeah, in theory but not in practice
14:58:35 jangutter stephenfin: there's no easy way to answer the question: "does this cloud support this VNIC type" without trying to spawn an instance.
14:58:56 openstackgerrit Matt Riedemann proposed openstack/os-traits master: Add COMPUTE_SAME_HOST_COLD_MIGRATE trait https://review.opendev.org/666604
14:59:32 jangutter stephenfin: your first NACK might be neutron saying "this combination of driver + vnic type is not valid". But it could go right up to Nova failing to find a free PCI device conforming to the NUMA topology.
15:00:06 stephenfin How did I ever get dragged into this stuff? :D
15:00:09 kashyap aspiers: I need to get back to this, afraid. Saddled with another meeting
15:00:29 aspiers kashyap: np
15:00:43 stephenfin jangutter: That does clarify some things
15:00:47 stephenfin ...though
15:00:49 jangutter stephenfin: in them olden days, I think there was a field that you could set that could select e1000 or realtek or something.
15:01:05 jangutter stephenfin: confusingly that was called vif type.
15:01:14 kashyap aspiers: But I _did_ ask the question to libvirt folks if there's any other way than injecting the "IOMMU on" at device config time
15:01:20 kashyap [If the device is 'virtio']
15:01:20 aspiers kashyap: thanks for that
15:01:20 gibi Sundar: do you mean L376 ?
15:01:23 kashyap I'll keep you posted
15:02:14 aspiers kashyap: I don't expect there to be. I was more wondering whether it should be done device by device, or near the end of instance config time, after all devices have already been constructed
15:02:15 Sundar gibi: Yes, sorry for the typo
15:02:26 aspiers kashyap: but this is just a matter of how to construct the guest XML
15:02:29 gibi Sundar: OK, reading the discussion
15:02:40 Sundar Thanks
15:02:56 kashyap aspiers: While I'm zoned out on the call, a quick questioN:
15:02:57 kashyap ...
15:02:57 kashyap if ('virtio' in info['bus'] and
15:02:57 kashyap self._sev_required(...):
15:02:57 kashyap cfg.driver_iommu = True
15:02:59 kashyap ...
15:03:14 kashyap aspiers: Shouldnt that be "or", instead of "and"?
15:03:23 aspiers no
15:04:09 aspiers from the spec: "The iommu attribute is on for all virtio devices. Despite the name, this does not require the guest or host to have an IOMMU device, but merely enables the virtio flag which indicates that virtualized DMA should be used. This ties into the SEV code to handle memory encryption/decryption, and prevents IO buffers being shared between host and guest."
15:04:55 jangutter stephenfin: Neutron's checks can look like this: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#L80
15:06:06 kashyap aspiers: I see, thanks for the context.
15:07:46 mriedem Sundar: replied
15:10:25 Sundar mriedem: Thanks. "If we agree to add a "fail on binding timeout" option" --> IUC, you are not saying that the option must be added. Only that, if we were to add it, it should be named a certain way, right?
15:15:59 melwitt mriedem: thanks, replied and +W on the bottom change
15:17:06 mriedem Sundar: correct, though i tend to think we should add that option
15:17:47 mriedem melwitt: thanks
15:19:14 aspiers efried: what else needs to go in https://review.opendev.org/#/c/664397/ ?
15:20:33 efried aspiers: Nothing currently known. Could approve it now, or could wait until we're pretty sure the series is a go.
15:20:55 aspiers efried: let's get it in now - I can easily submit follow-ups if needed
15:21:16 efried okay, +2 (someone else still needs to push it)
15:21:23 aspiers thanks
15:21:31 aspiers stephenfin maybe?
15:22:48 openstackgerrit Adam Spiers proposed openstack/nova master: Add extra spec parameter and image property for memory encryption https://review.opendev.org/664420
15:23:00 aspiers efried: ^^^ s/ers/ed/
15:23:26 efried +2
15:24:23 stephenfin aspiers: Sure, but not for another hour at least
15:24:29 aspiers stephenfin: np
15:25:20 gibi Sundar: replied too
15:31:41 Sundar gibi: Thanks. I responded back. Please take a look. Happy to answer any questions you may have.
15:33:08 gibi Sundar: replied. If the VM cannot use the accelerator when it is finally bound then I dont see why we let the VM boot up
15:36:05 mriedem Sundar: gibi: replied as well
15:36:23 mriedem i didn't realize that we have to wait for the bind event to then get config information to put into the domain xml for the guest,
15:36:49 mriedem that is a difference from how the port binding event loop works with nova - with ports we have the config to build the domain xml before the plugged event happens
15:36:57 mriedem we're just waiting for neutron to tell us that we're ok to proceed
15:37:20 gibi mriedem, Sundar: yeah that seems like a big difference to em
15:37:20 gibi me
15:37:31 mriedem in that case i agree if we have to wait to get the necessary information to build the domain xml, and if we timeout and don't have that information, then we need to fail
15:38:33 Sundar gibi, mriedem: Agreed. The analogy with Neutron does not hold here (as in many other cases). So, we all agree to leave out the arq_bind_timeout_is_fatal option, right?
15:38:56 gibi I agree to leave that config out
15:39:02 sean-k-mooney well it kind of does but in a diffeernt way
15:39:17 sean-k-mooney we dont know how to generate teh xml until after we bind the port
15:39:39 sean-k-mooney the delta is that binding is asyconus for cyborge
15:40:01 sean-k-mooney for neutron we get the vif_type back synconouly when we call the bind api
15:40:13 sean-k-mooney so we dont need to wait for it to be plugged
15:40:29 mriedem yeah we're confusing bind and plug here
15:40:41 sean-k-mooney but ya if we timeout i think we need to fail
15:41:33 sean-k-mooney because we cant generate the xml without the info form cyborg
15:42:15 Sundar sean-k-mooney, mriedem, gibi: Thanks, and agreed. So, once I fix the formatting issues that mriedem mentioned, we are ready to merge this one, right?
15:42:40 sean-k-mooney i dont have any outstanding issue with the current version
15:42:47 sean-k-mooney ignoring formating
15:42:57 openstackgerrit Adam Spiers proposed openstack/nova master: Add a new CONF.libvirt.num_memory_encrypted_guests option https://review.opendev.org/662105
15:42:58 openstackgerrit Adam Spiers proposed openstack/nova master: Add extra spec parameter and image property for memory encryption https://review.opendev.org/664420
15:43:17 mriedem Sundar: the formatting can be a follow up, i'll +2
15:43:17 gibi Sundar: I will +2 it after the config is dropped
15:43:28 openstackgerrit Adam Spiers proposed openstack/nova master: Use fake flavor instead of empty dict in test https://review.opendev.org/662555
15:43:29 openstackgerrit Adam Spiers proposed openstack/nova master: Pass extra_specs to flavor in vif tests https://review.opendev.org/662556
15:43:29 openstackgerrit Adam Spiers proposed openstack/nova master: Extract SEV-specific bits on host detection https://review.opendev.org/636334
15:43:30 openstackgerrit Adam Spiers proposed openstack/nova master: Add element to guest config for AMD SEV https://review.opendev.org/636318
15:43:30 openstackgerrit Adam Spiers proposed openstack/nova master: Allow guest devices to include https://review.opendev.org/644564
15:43:31 openstackgerrit Adam Spiers proposed openstack/nova master: Detect that SEV is required and enable iommu for devices https://review.opendev.org/644565
15:43:31 openstackgerrit Adam Spiers proposed openstack/nova master: Use element when SEV is required https://review.opendev.org/662557
15:43:32 openstackgerrit Adam Spiers proposed openstack/nova master: Enable memory locking if SEV is requested https://review.opendev.org/662558
15:43:32 openstackgerrit Adam Spiers proposed openstack/nova master: Track inventory for new MEM_ENCRYPTION_CONTEXT resource class https://review.opendev.org/666616
15:43:33 openstackgerrit Adam Spiers proposed openstack/nova master: WIP: Document AMD SEV support for encrypted VMs in libvirt https://review.opendev.org/666617

Earlier   Later