Earlier  
Posted Nick Remark
#openstack-nova - 2018-10-15
20:26:21 efried it's not a *capability*
20:26:24 efried But it is a *trait*.
20:26:26 efried Dammit.
20:26:31 mriedem it's a....thing
20:27:18 cfriesen is it schedulable?
20:27:18 mriedem what's the point of that being a trait? so we can schedule to a specific PCI address?
20:27:25 efried yes
20:27:30 efried pets, baby.
20:27:36 mriedem huh
20:27:48 cfriesen but can't the IOMMU redirect to whatever virtual address is desired?
20:27:48 efried more realistically, trait for vendor/product ID.
20:28:24 mriedem i seem to remember people saying we weren't going to allow scheduling to that level of granularity, like down to host numa node and such
20:28:40 efried I do this weekly now, look up 'trait' in the dictionary to assure myself that 'capability' is nowhere in the definition. Also not in the thesaurus.
20:28:50 cfriesen wouldn't "pci devices with a given vendor/product-id" be a countable resource ?
20:29:16 efried cfriesen: "PCI device" is the countable resource. "Vendor ID" and "Product ID" are traits. (But not capabilities)
20:29:30 efried I mean, arguably they're metadata (key/value).
20:29:35 efried But since we don't have that...
20:29:51 cfriesen I'd suggest that a whole set of capabilities are implied by the vendor/product
20:29:57 efried Completely agree.
20:30:20 efried But that overlaps with a set of capabilities implied by a different vendor/product.
20:30:38 efried In a perfect world, we would have a zillion individual traits for each of those capabilities
20:30:43 efried but
20:30:43 efried and I would schedule based on those capabilities
20:30:48 efried it is not a perfect world
20:30:57 efried where vendors are going to supply us handy dandy tables of those capabilities
20:31:02 cfriesen ick...then you'd need to specify which drivers are in your image, and suport all of them.
20:31:03 efried so we have to make do with what we've got.
20:31:09 mriedem so this is the thing where because we don't have metadata on resource providers, we're going to have super-encoded traits right?
20:31:11 efried yeah, something like that.
20:31:19 mriedem CUSTOM_NOVA_PCI_VENDOR_FOO_PRODUCT_BAR?
20:31:49 efried because then I can schedule based on required=in:{buncha vendor/product IDs that have the capabilities I need}, whereas if it was encoded in the resource class, that would not be possible.
20:32:15 efried mriedem: CUSTOM_NOVA_PCI_VENDORID_FOO and CUSTOM_NOVA_PCI_PRODUCTID_BAR, separate traits, but yeah.
20:32:59 cfriesen efried: is there a logical AND in there? since different vendors can have the same product ID
20:33:39 efried cfriesen: The boolean logic that's possible with `required` is not complete, but should be rich enough to get where you need to be.
20:34:13 cfriesen efried: I think you'd need something like ((A AND B) OR (C AND D))
20:34:17 efried btw, this idea is far from having any kind of consensus behind it. There are certain people who will need to be cold underground before it becomes reality.
20:35:25 efried cfriesen: True, and I don't think you can quiiite get there actually. What are the odds of ((A or C) AND (B OR D)) winding up meaningfully different in such a way that it actually hits a wrong device?
20:36:48 efried i.e. ((vendorA or vendorC) AND (productB or productD)) when what you really want is ((vendorA and productB) or (vendorC and productD)) => what are the chances that (vendorA+productD) or (vendorB+productC) actually exist?
20:39:23 cfriesen well, each vendor ID is unique, but I think product IDs are only unique within a given vendor
20:40:31 cfriesen but we may be lucky and not have overlap for commonly-used devices.
20:48:18 edleafe efried: don't put too much weight on the name 'trait'. That itself was a compromise betwee those who wanted them named 'capability' and those who wanted 'tag'
20:48:31 edleafe efried: It was always supposed to represent capabilities
20:51:43 efried I'll certainly admit that if they were called 'capabilities' I would not argue as strongly to put stuff like product IDs in them.
20:51:56 efried But they ain't.
20:52:09 efried Juliet had something to say about this. And look how that turned out.
20:53:58 edleafe "A capability by any other name would still generate semantic arguments..."
20:53:59 cfriesen so where are we at for HPET (and vTPM)? I'd suggest that for vTPM it's actually a capability since it depends on hypervisor version and such. For HPET it's two things: 1) asking for it where currently it's turned off unconditionally, and 2) maybe allowing operators to refuse to provide it.
20:54:50 mriedem cfriesen: my current question on the hpet spec is who sets the trait
20:55:10 mriedem i assumed it was set externally but was told the virt driver would set it, so started pulling the thread of how the virt driver would set it since that wasn't in the spec
20:56:36 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: don't log error if guest gone during interface detach https://review.openstack.org/610727
20:57:29 cfriesen mriedem: so as far as I know the LibvirtDriver when used with qemu/kvm could unconditionally set it, unless we want to add a config option to allow operators to explicitly enable it.
20:57:47 cfriesen mriedem: with qemu it seems to be purely emulated, unrelated to the host capabilities
20:58:01 cfriesen with other hypervisors I have no idea
20:58:21 cfriesen presumably with LXC or Xen it might use the real HPET
20:58:49 mriedem i don't really care about lxc honestly, we don't test it
21:04:52 mriedem lyarwood: methinks you have duplicate forum sessions https://www.openstack.org/summit/berlin-2018/summit-schedule/global-search?t=yarwood
21:10:54 cfriesen mriedem: dansmith: looks like this was the original reason why HPET was removed unconditionally from x86 guests: https://blueprints.launchpad.net/nova/+spec/add-no-hpet-option-into-guest-clock
21:41:59 lbragstad is anyone here planning on going to https://www.openstack.org/summit/berlin-2018/summit-schedule/#day=2018-11-13 ?
21:42:09 lbragstad sorry - wrong link https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22785/change-of-ownership-of-resources
21:42:58 lbragstad i noticed it's at the same time as the project update
21:45:53 efried which project update?
21:46:38 lbragstad nova's
21:47:34 mriedem artom: and i've left comments in https://review.openstack.org/#/c/587439/
21:47:35 mriedem as requested
21:52:03 mriedem lbragstad: yes i plan on going to that, and assume dansmith will also
21:52:33 dansmith yarp
21:52:58 lbragstad ok - so that over the project update i assume?
21:53:28 lbragstad nova's project update*
21:54:25 mriedem ask melwitt
21:54:36 mriedem i'd like to heckle at both
21:54:37 mriedem if possible
21:55:18 lbragstad same - minus the heckling
21:56:30 mriedem stephenfin has a presentation at the same time too
21:56:39 mriedem https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22582/how-to-double-the-performance-of-vswitch-based-deployments
21:57:34 mriedem hmm, for some reason my schedule isn't showing me all the things i've marked either..
21:57:59 lbragstad ?
21:58:09 mriedem oh nvm
21:58:18 lbragstad did you turn it off and back on again?
21:58:25 mriedem switching between days and tracks
21:58:37 mriedem i jiggled the handle
22:06:40 artom mriedem, much thanks! Supper time for me now, but I'll try to address both patches before sleep
22:20:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Move live_migration.pre.start to the start of the method https://review.openstack.org/610739
22:25:40 openstackgerrit Eric Fried proposed openstack/nova master: Reject forced move with nested source allocation https://review.openstack.org/605785
22:25:58 openstackgerrit Eric Fried proposed openstack/nova master: Run negative server moving tests with nested RPs https://review.openstack.org/604125
22:26:38 openstackgerrit Eric Fried proposed openstack/nova master: Handle allocations consuming only from the child RPs https://review.openstack.org/608298
22:30:56 mriedem dansmith: you probably want to get these pike backports of that host aggregate case name revert thing https://review.openstack.org/#/q/topic:bug/1709260+(status:open)
23:24:04 alex_xu melwitt: I'm good at Oct 23
23:48:32 openstackgerrit Artom Lifshitz proposed openstack/nova master: Handle volume API failure in _post_live_migration https://review.openstack.org/609517
#openstack-nova - 2018-10-16
00:08:33 melwitt alex_xu: ack, thanks
00:48:29 openstackgerrit Artom Lifshitz proposed openstack/nova master: Ensure attachment cleanup on failure in driver.pre_live_migration https://review.openstack.org/587439
02:45:06 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py https://review.openstack.org/566153
03:37:43 openstackgerrit Merged openstack/python-novaclient master: Add support for microversion 2.67: BDMv2 volume_type https://review.openstack.org/609743
07:37:17 bauzas good morning nova
07:40:06 openstackgerrit Jan Gutter proposed openstack/os-vif master: Extend host_info to cover port profiles https://review.openstack.org/610636
08:01:00 dpawlik morning
08:01:15 dpawlik quick question: why nova service-list shows me ID instead of UUID ?
08:13:38 openstackgerrit Merged openstack/nova stable/rocky: Handle missing marker during online data migration https://review.openstack.org/608572
08:29:05 fghaas kashyap: taking the liberty to follow up on https://review.openstack.org/#/c/609788 which you asked me to take a stab on. If you could give that a read to make sure that I didn't chuck in anything stupid, I'd be grateful. Thanks!
08:30:52 kashyap fghaas: Hey
08:31:09 kashyap fghaas: I did see the email, and even partly reviewed it. But was buried in preparing a conference talk

Earlier   Later