| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-08 | |||
| 18:22:00 | jaypipes | mriedem: well, not *really* but it can be seen as more of a bug fix that enables drivers like vcenter and powervm | |
| 18:23:44 | mriedem | ok, but we're not prioritizing sharing providers in rocky right? | |
| 18:23:46 | mriedem | *queens | |
| 18:23:58 | cdent | mriedem: it's discussed near here at today's meeting http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-01-08-14.00.log.html#l-127 | |
| 18:24:07 | cdent | it's not clear what the time table is | |
| 18:24:25 | mriedem | it's a rhetorical question :) | |
| 18:24:33 | mriedem | we said in denver that we weren't focusing on sharing providers in queens | |
| 18:24:37 | mriedem | and nested resource providers was the goal | |
| 18:25:05 | cdent | sure, I'm not disputing that. I'm merely asking where management of aggregates fits in | |
| 18:25:13 | mriedem | do aggregates butt up against nested providers? | |
| 18:25:25 | cdent | I'm very happy to not do the work, but in the meeting it was wanted. If we don't want it, cool. | |
| 18:25:30 | mriedem | "butt up" is the technical term | |
| 18:25:36 | cdent | quite | |
| 18:25:38 | mriedem | well, want is fine, | |
| 18:25:47 | mriedem | i just don't want it to be a distraction for queens | |
| 18:25:55 | mriedem | queuing it up for rocky is cool | |
| 18:26:16 | mriedem | reminds me i need to start an etherpad for various rocky ptg stuff, to include spill over from queens | |
| 18:26:22 | cdent | I'm happy to let jaypipes and efried decide. I simply volunteered to do the implementation. | |
| 18:27:13 | jaypipes | mriedem: rocky is fine | |
| 18:27:59 | mriedem | cdent: jaypipes: https://etherpad.openstack.org/p/nova-ptg-rocky | |
| 18:28:10 | cdent | ack | |
| 18:28:10 | mriedem | now i've forgotten what i wanted to put on there from friday :( | |
| 18:28:19 | mriedem | oh yeah | |
| 18:29:31 | cdent | mriedem: If we're punting that to rocky, I don't reckon we need to put it on the ptg agenda, we talked it to deaht already today. I'm sure we'll have plenty of stuff more interesting. So I'll kill it. | |
| 18:30:12 | mriedem | i'll at least target the bp to rocky in launchpad so it's in the list | |
| 18:30:42 | jaypipes | mriedem: the aggregate-affinity one would be good to add to the ptg agenda. I'll do that. | |
| 18:31:00 | mriedem | yeah definitely while we have ironic people around | |
| 18:57:31 | jaypipes | oh shitbuckets. | |
| 19:03:16 | openstackgerrit | Jay Pipes proposed openstack/nova master: func tests for nested providers in alloc candidate https://review.openstack.org/531443 | |
| 19:03:17 | openstackgerrit | Jay Pipes proposed openstack/nova master: add _has_provider_trees() utility function https://review.openstack.org/531474 | |
| 19:03:17 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: _get_trees_matching_all() https://review.openstack.org/531512 | |
| 19:10:31 | jaypipes | efried: for n-r-p traits handling, we agreed that the following is true, right? "if user requests traits X, Y, and Z and at least one provider within a tree has one of each of those traits associated with it, then collectively the tree meets the required traits constraint" | |
| 19:11:35 | jaypipes | efried: or did we instead say "the providers **that end up providing the resources involved in the request** must collectively be associated with all of the required traits"? | |
| 19:12:12 | jaypipes | edleafe, mriedem, dansmith: your thoughts welcome on ^^ | |
| 19:12:59 | dansmith | until we have the more expressive query language, neither is really what we want, right? | |
| 19:13:10 | dansmith | and we kinda have to do the "any" instead of "all" until that point I thought | |
| 19:16:18 | jaypipes | dansmith: let's say I have a compute node with 24 VCPU and 32768G RAM with two child providers representing two PFs. One PF has trait X and one has trait Y. The one with trait X has inventory available for 2 VFs. the PF has no more inventory of VFs. If I request 2 VCPU, 1024 MEMORY_MB and 1 SRIOV_NET_VF, along with required_traits=Y. should the compute node be returned? I would say "no"... | |
| 19:16:31 | dansmith | wow 32T of ram? | |
| 19:16:37 | jaypipes | heh | |
| 19:16:41 | jaypipes | you get my drift.. | |
| 19:17:06 | dansmith | it just means we have to tag everything with every trait right? | |
| 19:17:23 | dansmith | like you'd have to tag a compute node with "has-nvidia" so that you could ever get a gpu | |
| 19:19:05 | jaypipes | dansmith: no, that's not quite what I'm getting at... I'm wondering whether the "collectively meets the required traits constraint" should only consider those (child) resource providers that would be providing the resources for the request. In the case described above, the child provider that has the required trait Y does not provide the inventory of SRIOV_NET_VF for the request. Instead, the child provider with trait X is providing that | |
| 19:19:06 | jaypipes | inventory. | |
| 19:19:47 | dansmith | well, I think I get that, I'm just not sure how you're going to scope it to the right thing, | |
| 19:19:54 | jaypipes | but "collectively", the provider tree representing the compute node and all its child providers "meets the constraints" | |
| 19:20:03 | dansmith | meaning how placement is going to know that "has required trait X" applies to the vif and not the disk | |
| 19:20:25 | dansmith | since the query didn't scope it as such | |
| 19:20:35 | jaypipes | dansmith: well, I can apply the filter on traits *after* already processing the filter for resource amounts. | |
| 19:20:46 | dansmith | right, | |
| 19:20:53 | dansmith | which will filter out disks without trait X yes? | |
| 19:20:59 | jaypipes | right | |
| 19:21:09 | dansmith | which means you don't get any disk, which isn't a useful thing if you're trying to boot an instance, no? | |
| 19:22:06 | jaypipes | well, that would just mean that this compute node would not be returned in the GET /allocation_candidates query since the required traits are not associated with the providers that would end up providing the resources for the request | |
| 19:22:36 | dansmith | exactly | |
| 19:22:41 | dansmith | which is what I was saying: | |
| 19:22:51 | dansmith | you'd have to tag everything with X to make it come out properly | |
| 19:23:11 | dansmith | your disk and cpu and gpu would all have to have X applied so that you could ask for things with trait X, | |
| 19:23:31 | dansmith | but that doesn't make sense, assuming X is a networky trait you're using to pick which VF/PF/whatever you're looking for | |
| 19:23:37 | jaypipes | right | |
| 19:23:47 | dansmith | okay now I'm confused that you agree | |
| 19:23:57 | jaypipes | I think I've answered my own question :) | |
| 19:24:17 | dansmith | ....mmmokay :) | |
| 19:24:26 | jaypipes | just needed a willing sounding board. | |
| 19:24:32 | jaypipes | or unwilling I suppose ;) | |
| 19:24:54 | dansmith | heh | |
| 19:26:15 | mriedem | jaypipes: i don't know the answer to that - it was one of the questions i asked when that change in the placement api merged, i.e. "what are the rules on this new query parameter?" | |
| 19:26:32 | mriedem | specifically the "in_tree" parameter | |
| 19:26:52 | jaypipes | mriedem: this isn't about that parameter (that parameter doesn't exist for GET /allocation_candidates | |
| 19:27:10 | jaypipes | mriedem: but I can see a similar problem/point with that | |
| 19:34:53 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Collocate encryptor and volume driver calls https://review.openstack.org/460243 | |
| 19:36:57 | edleafe | jaypipes: (catching up) I wasn't clear if the tree for that compute node would contain everything (i.e., both child PFs), or only the children needed to satisfy the request | |
| 19:37:55 | jaypipes | edleafe: yes, tree would contain both PFs. | |
| 19:38:19 | edleafe | ah, ok | |
| 19:38:49 | edleafe | Just the allocation_candidate would be "minimal" | |
| 19:43:36 | jaypipes | edleafe: not sure I follow you.. | |
| 19:45:30 | edleafe | jaypipes: I wasn't clear if the provider tree would only contain parts of the entire tree that were "relevant" | |
| 19:46:07 | edleafe | since you were talking about meeting traits restraints | |
| 19:46:32 | jaypipes | edleafe: ah, so the provider_summaries will include all nodes in the tree, but the allocation_requests would only be the ones that were being consumed from. | |
| 19:46:51 | jaypipes | edleafe: but what I was wondering about was how to winnow the set of provider trees to begin with... | |
| 19:49:08 | edleafe | because the SQL can't be that specific? I.e., match trait to the PF with the inventory? | |
| 19:49:51 | jaypipes | edleafe: no, it's not really a SQL thing... more of a "what order do I apply this filter" thing... don't worry about it. I've got tests coming that show the idea. should be easier to read the tests. | |
| 19:51:51 | edleafe | jaypipes: ack | |
| 20:00:48 | openstackgerrit | Jay Pipes proposed openstack/nova master: add tests for _get_trees_matching_all() with trait https://review.openstack.org/531899 | |
| 20:01:08 | jaypipes | edleafe, mriedem, dansmith, efried: ^^ try that test description on for size... | |
| 20:05:28 | stvnoyes | mriedem: (I figured my problem, I neglected to set MA on the disk) So I was able to create a VM with a vol and did a bfv. I then created a new vm and attached the first vm's boot disk to it (as a data disk). I then did a nova image-create for both vm's. It all worked without errors. Was this the test you were looking for? | |
| 20:06:38 | mriedem | stvnoyes: yeah, that's what i have in https://review.openstack.org/266605 so far | |
| 20:07:34 | mriedem | stvnoyes: here is another one: create a bootable multiattach volume, create server1 from that volume with delete_on_termination=True; then create another server (not bfv) and attach the volume to server2, then delete server1 | |
| 20:07:45 | mriedem | assert that the volume is not deleted and still attached to server2, but server1 was deleted | |
| 20:08:00 | stvnoyes | kk | |
| 20:08:48 | mriedem | i'm going to add another test in here for resize with a multiattach volume attached | |
| 20:09:15 | mriedem | and we likely also need a test for swap volume with a multiattach volume, but that's an admin-level test | |
| 20:13:24 | mriedem | sdague: got a pretty easy +W on efried's neutronclient changes for the ksa adapter https://review.openstack.org/#/c/509892/ | |
| 20:14:05 | sdague | mriedem: looking | |
| 20:18:24 | edmondsw | mriedem sdague the powervm SEA and OVS patches shouldn't merge until we get the CI working, which is waiting on a global req change to merge (already has +W), but they are otherwise ready to start reviewing | |
| 20:18:43 | edmondsw | OVS: https://review.openstack.org/#/c/422512/ | |
| 20:18:52 | edmondsw | SEA: https://review.openstack.org/#/c/523216/ | |
| 20:40:45 | stvnoyes | it's 3:07 in my time zone | |
| 20:40:50 | mriedem | stvnoyes: mayhap you'd like to recreate and fix this https://bugs.launchpad.net/nova/+bug/1741476 | |
| 20:41:03 | stvnoyes | ok I'll take a look | |