| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-08 | |||
| 18:09:27 | mriedem | andreas is usually pretty quick to hit these though | |
| 18:10:01 | dtantsur | yep | |
| 18:10:14 | mriedem | dtantsur: does ironic-tempest-dsvm-ipa-wholedisk-agent_ipmitool-tinyipa-multinode also test the multitenant stuff? | |
| 18:10:24 | mriedem | *multitenant network | |
| 18:10:30 | dtantsur | mriedem: that's the correct name of that job, so yes | |
| 18:10:46 | mriedem | oh maybe it was renamed and we just never noticd | |
| 18:10:54 | dtantsur | I think so | |
| 18:14:26 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Ironic: Get IP address for volume connector https://review.openstack.org/468353 | |
| 18:15:42 | jaypipes | mriedem, jgriffith_: your thoughts on this? https://review.openstack.org/#/c/528740/ | |
| 18:16:05 | mriedem | jaypipes: we can't change that as a bug fix | |
| 18:16:06 | mriedem | imo | |
| 18:16:14 | mriedem | it's an api change | |
| 18:16:24 | jaypipes | mriedem: oh, I agree... I don't think it's actually something we should do *at all*. | |
| 18:16:26 | mriedem | https://blueprints.launchpad.net/nova/+spec/volume-backed-server-rebuild | |
| 18:17:05 | mriedem | i've -2ed for now just due to procedure | |
| 18:17:25 | mriedem | i'm sure people want rebuild of volume-backed instances, but i'm not interested in that rats nest atm | |
| 18:19:16 | cdent | efried, jaypipes I've stubbed in https://blueprints.launchpad.net/nova/+spec/placement-aggregate-generation . Since it is microversion, officially we need a spec. | |
| 18:19:42 | ameeda | Hi , when I try to execute this command "mistral-db-manage --config-file /etc/mistral/mistral.conf populate", I got many errors as this http://paste.openstack.org/show/640994/ | |
| 18:20:25 | jaypipes | cdent: you want to handle the spec? | |
| 18:20:33 | cdent | yeah, will do | |
| 18:20:47 | mriedem | that's rocky at this point right? | |
| 18:20:57 | jaypipes | ameeda: wrong channel... try #openstack-mistral | |
| 18:21:08 | ameeda | Thanks ! | |
| 18:21:14 | jaypipes | mriedem: which one? | |
| 18:21:22 | jaypipes | mriedem: the placement agg gen? | |
| 18:21:24 | mriedem | aggregates generation | |
| 18:21:37 | mriedem | or is that blocking something for queens? | |
| 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 | mriedem | now i've forgotten what i wanted to put on there from friday :( | |
| 18:28:10 | cdent | ack | |
| 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: placement: _get_trees_matching_all() https://review.openstack.org/531512 | |
| 19:03:17 | openstackgerrit | Jay Pipes proposed openstack/nova master: add _has_provider_trees() utility function https://review.openstack.org/531474 | |
| 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. | |