| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-29 | |||
| 14:37:52 | artom | Well | |
| 14:37:56 | mriedem | i thought that was just ports and volumes? | |
| 14:38:04 | artom | I don't think we ever explicitly decided what to do about PFs | |
| 14:38:15 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/sriov-pf-passthrough-neutron-port-vlan.html | |
| 14:38:17 | artom | But since a PF can be a neutron port, they're implicitly taggable? | |
| 14:38:20 | mriedem | ^ is what i'm thinking of | |
| 14:38:34 | artom | That's vlans, slightly different | |
| 14:38:47 | artom | But... I don't think those are working either, btw | |
| 14:38:53 | mriedem | great! | |
| 14:38:59 | artom | vladikr had a thing up to fix it | |
| 14:39:03 | artom | And his approach never made sense to me | |
| 14:39:06 | artom | Maybe this is why | |
| 14:39:07 | mriedem | red hat QE strikes again 2 years late | |
| 14:39:34 | artom | (Speaking of QE, we found a problem with the scheduler bypass CVE fix for the fix) | |
| 14:39:42 | artom | (Barely a week later!) | |
| 14:39:50 | mriedem | the error case? | |
| 14:39:52 | mriedem | that we fixed last week? | |
| 14:40:01 | artom | mriedem, yeah, if you rebuild again with the same image it goes through | |
| 14:40:10 | artom | Because there's a new image == old image check in the API | |
| 14:40:25 | artom | I don't have an upstream bug filed yet, but here: https://bugzilla.redhat.com/show_bug.cgi?id=1539703 | |
| 14:40:26 | openstack | bugzilla.redhat.com bug 1539703 in openstack-nova "By rebuilding twice with the same "forbidden" image one can circumvent scheduler rebuild restrictions" [Unspecified,New] - Assigned to eglynn | |
| 14:41:25 | mriedem | oh b/c we didn't reset the image on failure in the scheduler | |
| 14:41:34 | artom | mriedem, https://review.openstack.org/#/c/468758/ vladikr's PF vlan thing | |
| 14:41:38 | mriedem | which is what int32bit's patch was originally doing until i talked him out of it | |
| 14:41:52 | artom | His solution was to refresh info_cache, which seems weird | |
| 14:42:02 | artom | mriedem, well, properly rolling the changes back isn't trivial | |
| 14:42:12 | mriedem | artom: yeah i know, which was my argument in the patch. | |
| 14:42:25 | mriedem | let's just revert rebuild | |
| 14:42:42 | artom | Our of the nova api entirely? 100% behind you :) | |
| 14:43:05 | mriedem | i'll add that bz to the queens rc etherpad | |
| 14:43:22 | artom | mriedem, I'll file a proper launchpad soon | |
| 14:44:20 | mriedem | ok thanks. i think this is an easy, albeit slightly ugly fix. | |
| 14:44:54 | artom | We've said that, what, 3 times now? | |
| 14:45:11 | mriedem | jianghuaw: just to confirm, basic vgpu support for xenapi is merged, correct? the remaining patches are future work for integrating with nested resource providers? | |
| 14:45:28 | mriedem | artom: but this time it's for real | |
| 14:46:27 | mriedem | melwitt: some updates on the cellsv1 job in stable issues over the weekend - i finally opened a bug to track it https://bugs.launchpad.net/nova/+bug/1745838 | |
| 14:46:28 | openstack | Launchpad bug 1745838 in OpenStack Compute (nova) "legacy-tempest-dsvm-cells constantly failing on stable pike and ocata due to libvirt connection reset" [Undecided,New] | |
| 14:47:17 | mriedem | melwitt: and it gets a bit messy, but we need to merge the changes to bump the nova-functional job timeouts, but for that to help, we need to drop the openstack-tox-functional jobs from running on nova, which depends on these changes in stable https://review.openstack.org/#/q/Ia684786d1622da7af31aa4479fc883a7c65848ff | |
| 14:47:34 | mriedem | those changes in stable kept failing the cellsv1 job, so i stopped running the cellsv1 job on stable: https://review.openstack.org/#/c/538619/ | |
| 14:47:45 | jianghuaw | mriedem, yes for basic vgpu support. | |
| 14:48:02 | mriedem | jianghuaw: thanks | |
| 14:51:02 | bauzas | mriedem: jianghuaw: I'm working on a matrix patch that'll add the vgpu support | |
| 14:51:18 | bauzas | mriedem: jianghuaw: I'll CC you the patch once I'm done | |
| 14:51:25 | jianghuaw | bauzas, thanks. | |
| 14:51:45 | bauzas | I also have in my pipe a possible functional test for testing server actions with VGPUs | |
| 14:52:00 | bauzas | but it requires me some fixture investigation | |
| 14:52:25 | jianghuaw | bauzas, I think display head is not in queens' plan. right? Although I have a patch for that. | |
| 14:52:30 | jianghuaw | https://review.openstack.org/#/c/523342 | |
| 14:52:44 | bauzas | jianghuaw: Queens is done now | |
| 14:52:57 | bauzas | for features I mean | |
| 14:53:19 | sauloaugusto | Is there any channel for mova upgrade support ? | |
| 14:53:39 | jianghuaw | I see. the freeze-date has passed. | |
| 14:54:16 | jianghuaw | bauzas, I don't expect that can be merged:-) | |
| 14:54:40 | mriedem | melwitt: and at this point, ironically the nova-functional patches on stable are failing b/c of the openstack-tox-functional job timeouts, which we're trying to fix here, but we can't recheck anything until zuul is fixed | |
| 14:57:31 | mriedem | melwitt: oh btw, the cellsv1 job failures started around 1/18 which is around the same time as that python2.7 update in xenial repos, which was causing other gate instability related to eventlet not monkey patching os.open, | |
| 14:57:47 | mriedem | so i wondered if maybe there is some issue in libvirt-python or something in the older versions we're using on stable | |
| 15:01:24 | efried | cdent You've got me confused. | |
| 15:01:26 | jaypipes | efried, cdent: reading the vmware mail thread now.. | |
| 15:01:43 | cdent | efried: that's my goal in life | |
| 15:01:47 | efried | jaypipes cdent Note there's a followup that did go to the -dev ML. | |
| 15:02:13 | efried | cdent The part I'm confused about is: where were we ever talking about "negative traits"? | |
| 15:02:22 | cdent | we weren't | |
| 15:02:40 | jaypipes | efried: there's no such thing as a negative trait. | |
| 15:02:50 | jaypipes | efried: something either has or doesn't have a trait. | |
| 15:02:53 | cdent | we were talking about how to not consume resources that have a trait when we don't care about that trait | |
| 15:03:01 | efried | We were? | |
| 15:03:13 | jaypipes | cdent: resources don't have traits. providers have traits. | |
| 15:03:28 | cdent | jaypipes: I know, but naming it hard | |
| 15:03:41 | jaypipes | cdent: did you mean consuming resource from a provider that doesn't have a trait? | |
| 15:03:54 | cdent | jaypipes: no | |
| 15:03:57 | cdent | let me explain | |
| 15:04:10 | cdent | given two providers with equal inventory, one has trait X | |
| 15:04:21 | jaypipes | efried: do you want me to respond to the ML part and not the private email? | |
| 15:04:55 | cdent | we make a query for allocation candidates that both poviders can satisfy | |
| 15:05:06 | cdent | how do we say "don't use the provider that has trait X" | |
| 15:05:07 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/pike: tests: Use correct response type in tests https://review.openstack.org/538938 | |
| 15:05:19 | efried | Perhaps it would be best if cdent replied to the ML one with whatever's still relevant from the private thread; then you can respond to that. Keep the thread linear-ish. | |
| 15:05:21 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/pike: Handle images with no data https://review.openstack.org/538939 | |
| 15:05:24 | gibi | ameeda: sure, you can get sysmeta from the db, but I thought, based on the comments, that you are trying to find a way to get sysmeta via the REST API | |
| 15:05:25 | jaypipes | cdent: you don't. you just don't include the trait in required_traits= param. | |
| 15:05:36 | jaypipes | cdent: it's a sorting/weighing/preference problem, not a filtering problem. | |
| 15:05:54 | cdent | jaypipes: right, that's basically what I say at the end of my message | |
| 15:05:58 | openstackgerrit | Stephen Finucane proposed openstack/nova stable/pike: Handle images with no data https://review.openstack.org/538939 | |
| 15:05:59 | jaypipes | gotcha | |
| 15:06:11 | efried | cdent But I don't see how that's relevant to the discussion | |
| 15:06:34 | efried | I totally didn't pick up on any part of rado's original note that implied we needed/wanted to do that. | |
| 15:07:11 | mriedem | stephenfin: question in that backport | |
| 15:07:26 | cdent | efried: rado was expressing concern about allocations being made to the wrong pool when not expressing the trait | |
| 15:07:27 | jaypipes | efried: the fundamental problem with the vmware conversation is that resource pools are being represented with nested providers instead of aggregates. aggregates are the thing that provides the "grouping" concept that the resource pools represent. nested providers represent a different relationship: that of dependent trees of providers. | |
| 15:07:42 | cdent | "is there a way to make the scheduler allocate only from one specific RP if no custom trait is specified in the request" | |
| 15:08:09 | efried | Heh. Oh. I took a much simpler approach to that question. It went like this: "No." | |
| 15:08:58 | cdent | The complicating factor here is that I think nested is _exactly_ the model for how resource pool are supposed to work | |
| 15:08:59 | efried | jaypipes ++ and in fact trying to use NRP for pools will break horribly | |
| 15:09:21 | efried | oh, wow, okay, clearly starting on opposite ends of the rope. | |
| 15:09:37 | efried | cdent Can you describe that hierarchy please? | |
| 15:09:41 | cdent | because they represent a hierarcy of containment | |
| 15:10:21 | cdent | so, nrp came about in part because of numa and pci relationships, right? | |
| 15:10:30 | efried | cdent Have you seen the response I made to the ML yet? I want to baseline and make sure I've got my idea of the hierarchy down before we go any further. | |
| 15:10:47 | cdent | efried: yes, I've read it twice and still trying to make sure i understand it | |
| 15:10:54 | efried | k | |