| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-15 | |||
| 20:22:16 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: Use tempfile for powervm config drive https://review.openstack.org/610174 | |
| 20:22:22 | mriedem | namespace custom traits? | |
| 20:22:27 | mriedem | i thought CUSTOM_* was it? | |
| 20:22:43 | mriedem | dansmith: yeah b/c some ops want to disable it... | |
| 20:23:10 | dansmith | yeah, so I definitely thought this was going to be an actual capability, not just a "is this turned on" sort of thing when we last discussed it | |
| 20:23:26 | dansmith | not even is it turned on, but is it in policy for this host | |
| 20:24:03 | efried | mriedem: namespaced to signify the owner. Like if the trait.startswith('CUSTOM_NOVA_') then the op isn't allowed to touch it. Otherwise, fair game. | |
| 20:24:17 | efried | ...until CUSTOM_CYBORG_ is a thing, etc. | |
| 20:24:51 | efried | but at least then we have to have a short hardcoded list of possible owners and their namespaces, rather than a long hardcoded list of individual traits (or trait regexes) that are system-owned. | |
| 20:24:59 | mriedem | are there any cases where we'll have CUSTOM_NOVA_* traits that aren't just standard traits in os-traits? | |
| 20:25:23 | mriedem | CUSTOM_NOVA_* sounds pretty not custom to me | |
| 20:25:25 | efried | mriedem: An example would be a trait signifying the PCI address of a device. | |
| 20:26:13 | mriedem | is that a trait? | |
| 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 | |