| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-15 | |||
| 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 | |
| 08:31:17 | kashyap | (Also incidentally related to CPU models) | |
| 08:31:32 | kashyap | fghaas: I'll definitely look at it by EOD, I have it open. Sorry for the delay | |
| 08:31:43 | fghaas | I'm so surprised that your conf talk would be about *that*, of all things. ;) | |
| 08:31:52 | kashyap | Heh | |
| 08:32:02 | kashyap | Will you be in Edinburgh? | |
| 08:32:11 | kashyap | (Open Source Summit & KVM Forum) | |
| 08:33:05 | fghaas | No I won't. They waitlisted my talk, but it didn't get in. | |
| 08:33:34 | fghaas | But I will be in Berlin assuming you're headed there. | |
| 08:34:03 | dpawlik | nvm about my question. I didn't saw that there is nova and nova_legacy service type | |
| 08:34:20 | kashyap | fghaas: Yeah, will be there | |
| 08:34:46 | fghaas | Perfect. I still owe you dinner or at least a drink for your help with nesting and migration. | |
| 08:47:10 | kashyap | fghaas: No, don't be crazy | |
| 08:47:21 | kashyap | :-) | |
| 08:47:38 | kashyap | fghaas: Did a quick review, posted a couple of comments. Looks largely good. | |
| 08:48:52 | kashyap | (And yes, a drink in Berlin does sound good.) | |
| 08:50:53 | fghaas | oh, beamer. That's something my little brain is incapable of grasping. :) | |
| 08:51:19 | kashyap | fghaas: I hate myself for the amount of time I spend on it. But I love its typography | |