| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-29 | |||
| 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 | |
| 15:11:34 | stephenfin | mriedem: Reply left. tl;dr: I think we're fine for stable/pike | |
| 15:11:55 | stephenfin | assuming I'm reading g-r correctly | |
| 15:12:05 | mriedem | we just need 2.8.0? | |
| 15:12:13 | cdent | the thing about your model which is not necessarily desirable is the way in which esxi hosts are managed as a concrete resources. vcenter doesn't really want to do that (although it is possible and would be a reasonable fallback) | |
| 15:12:18 | stephenfin | mriedem: 2.6.0+ | |
| 15:13:02 | efried | jaypipes The aggregate model won't allow you to request a deploy to a specific resource pool. But maybe I'm misunderstanding the original intent, which I thought was to do just that. | |
| 15:13:42 | cdent | the intent is to deploy to a specific resource pool | |
| 15:14:12 | cdent | if you have an aggregate for each specific resource pool, that might be workabe | |
| 15:14:30 | efried | But you still can't deploy to a specific resource pool with just that. | |
| 15:14:42 | cdent | brb | |
| 15:14:44 | efried | You would have to have some other mechanism in place. | |
| 15:14:45 | mriedem | can you add a custom filter and custom scheduler hint which is just 'make it go directly here' | |
| 15:15:10 | jaypipes | efried: uhm, yeah you could request a specific aggregate... | |
| 15:15:19 | efried | jaypipes How? | |
| 15:15:28 | efried | With some mechanism yet to be designed? | |
| 15:15:46 | jaypipes | efried: we already have the member_of param. we can work that in to alloc candidates very easily. | |
| 15:16:08 | efried | okay, agree, but not yet designed or started. | |
| 15:16:23 | jaypipes | efried: of course, that would require the users knowing about the aggregate UUID/names... | |
| 15:16:31 | jaypipes | efried: which generally we have not encouraged. | |
| 15:16:41 | mriedem | stephenfin: got it | |
| 15:16:42 | mriedem | thanks | |
| 15:17:14 | mriedem | there is no aggregate name https://developer.openstack.org/api-ref/placement/#list-resource-provider-aggregates | |
| 15:17:33 | jaypipes | mriedem: sorry, UUID... | |
| 15:17:58 | jaypipes | efried: still, what is the root of the problem that is trying to be solved? | |