| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-19 | |||
| 16:28:02 | mriedem | i can't tell if it being a root or not matters | |
| 16:28:07 | efried | That's the thing. | |
| 16:28:18 | efried | We *do* want the virt to be able to mess with the sharing provider. | |
| 16:28:19 | mriedem | if my virt driver shouldn't mess with the sharing provider, why do i care if it's a root or not? | |
| 16:28:37 | mriedem | why? | |
| 16:28:45 | jaypipes | mriedem: this goes back to the powervm virt driver structure. | |
| 16:28:55 | cdent | efried: yes we do, but for those sharing providers that we want to mess with, do we want them to existing in a nested hieararchy? I would think/hope not. | |
| 16:28:57 | jaypipes | mriedem: they want the ability to manage storage pools in their virt driver. | |
| 16:28:59 | efried | As one example, yes. I think VCenter also had an example. | |
| 16:29:09 | cdent | vcenter's example is basically the same | |
| 16:29:15 | edleafe | efried: if the shared provider is the one with the inventory, it would be the one we allocate against, no? Why do we need its root provider? | |
| 16:29:35 | mriedem | the spec says, "Note, | |
| 16:29:35 | mriedem | however, that it may contain providers not directly owned/controlled by the | |
| 16:29:35 | mriedem | compute host. Care must be taken not to remove or modify such providers | |
| 16:29:35 | mriedem | inadvertently." | |
| 16:29:37 | jaypipes | edleafe: the virt driver doesn't allocate. | |
| 16:29:45 | dansmith | mriedem: rc2 is tagged, yeah? are we good to land the compute rpc thing now? | |
| 16:29:49 | efried | mriedem: Yes, there's that too. | |
| 16:29:50 | sean-k-mooney | jaypipes: just regarding those 2 os-vif changes you +2'd i am happy to merge them too but i think there may be an alternitive way to adress https://review.openstack.org/#/c/531358/ that would also work on centos but it might be tricky to do in the gate so ill run it by ye in dublin. | |
| 16:29:53 | mriedem | dansmith: sure | |
| 16:29:57 | mriedem | dansmith: i haven't looked at it yet | |
| 16:30:00 | edleafe | jaypipes: but I thought we were talking placement | |
| 16:30:17 | jaypipes | edleafe: we're talking virt driver's use of the ProviderTree struct | |
| 16:30:27 | dansmith | mriedem: okay, it's fairly straightforward and would like to land that soon before we break it of course | |
| 16:30:50 | efried | That's for e.g. sean-k-mooney's cases when there's like a bandwidth provider that's owned by neutron, but is part of the compute node's tree structure. | |
| 16:30:57 | mriedem | dansmith: i am now in update_provider_tree land | |
| 16:30:59 | jaypipes | sean-k-mooney: feel free to approve them then and we'll discuss in Dublin | |
| 16:31:10 | edleafe | jaypipes: sure, but we're also talking about shared providers linked to a compute node | |
| 16:31:14 | dansmith | mriedem: good luck with that | |
| 16:31:47 | sean-k-mooney | jaypipes: cool. i need to talk to stephen about how to add custom jobs via zullv3. i think i understand but i would like to get a linux bridge job there also | |
| 16:32:02 | cdent | can we, at least temporarily, make guideance that shared providers don't nest? Does that get us further down the road without having to predict everything? | |
| 16:32:07 | mriedem | efried: jaypipes: it doesn't seem like a good idea for the nova virt driver to be modifying things that aren't directly under nova's control, like compute resources - because if nova says it can mess with storage and network sharing providers, then cinder/neutron can also be mucking with those right? and we have a fun split brain problem. | |
| 16:32:11 | efried | cdent: It would, yes. | |
| 16:32:11 | kashyap | sean-k-mooney: I need to run to my Dutch class now; will add the blueprint tomm or later when I get back. | |
| 16:32:18 | cdent | or rather, if they do nest, we don't care about it | |
| 16:32:37 | edleafe | ^^ that | |
| 16:32:59 | cdent | because all we really need to know (for now) is that they are there | |
| 16:33:01 | efried | mriedem: Up to this point, virt.PowerVM has full control over the Shared Storage Pool. We want to keep it that way in Placement-land. | |
| 16:33:06 | jaypipes | mriedem: I'm not saying that it's my *preferred* architecture for a virt driver. but it is what it is.. | |
| 16:33:36 | sean-k-mooney | efried: at least for the bandwidth case the provider would not be a shared provider but it was going to be associated to the neutron agent by an aggregate | |
| 16:34:03 | efried | sean-k-mooney: Okay, maybe it was neutron owning the NICs/PFs? | |
| 16:34:12 | mriedem | efried: are those SSP's restricted to a single nova-compute service? | |
| 16:34:17 | sean-k-mooney | efried: in that case also not shared | |
| 16:34:21 | mriedem | or can multiple virt drivers be monkeying with the same SSP? | |
| 16:34:35 | efried | mriedem: The latter. We recognize and accept the caveats of co-management. | |
| 16:34:46 | sean-k-mooney | neutron would be creating RPs in the compute node tree in both cases however | |
| 16:34:54 | efried | ^ | |
| 16:35:37 | sean-k-mooney | mriedem: SSP? | |
| 16:35:48 | mriedem | shared storage pool | |
| 16:35:48 | efried | sean-k-mooney: Shared Storage Pool, PowerVM style in this case. | |
| 16:35:58 | sean-k-mooney | oh ya ok | |
| 16:36:27 | mriedem | ok so the spec says the virt driver can see these other things but shouldn't modify them, but then you're saying you totally do want to modify them and that's the intent | |
| 16:36:38 | efried | mriedem: No, those are different things. | |
| 16:36:42 | mriedem | in other words, update_provider_tree is a blank check to the virt driver | |
| 16:37:11 | mriedem | as we've seen with the RT managing allocations, | |
| 16:37:17 | mriedem | this is probably goign to end badly | |
| 16:37:34 | efried | The networky examples in sean-k-mooney's camp are going to be providers in the tree that's rooted at the compute node RP. Those are the ones virt should avoid mucking with. | |
| 16:37:36 | sean-k-mooney | efried: oh speaking of PowerVM as an aside it support PCI devices corret but does not expose pci address am i rembering that correctly. i mentioned it on stephenfin's numa aware vswitch spec but was not sure if i remembered correctly | |
| 16:38:05 | efried | sean-k-mooney: I haven't made it all the way through that spec yet, but will look out for that, thanks. | |
| 16:38:47 | mriedem | so non-compute child resource providers - don't touch; non-compute shared aggregate providers, go nuts | |
| 16:38:55 | efried | mriedem: Blank check, sort of. It's going to be important for the virt driver to understand what it's doing with its providers. | |
| 16:39:31 | mriedem | do you have an example of what a virt driver would need to do with a shared provider aggregate? | |
| 16:39:31 | efried | mriedem: The caveats are just caveats. If a virt driver figures out some way it's going to co-manage the providers neutron creates... that sounds weird but doable. | |
| 16:39:33 | sean-k-mooney | mriedem: well it depends for the neutron created resouce providers i had envisioned the nova conductor makeing the claims against them | |
| 16:40:04 | sean-k-mooney | mriedem: that said nova could delegate that to neutron as part of the port bind also | |
| 16:40:24 | mriedem | sean-k-mooney: are you talking about the bw based scheduling spec? | |
| 16:40:58 | mriedem | we want any kind of 'claim' happening before we hit a compute, which is where port binding happens | |
| 16:41:03 | sean-k-mooney | mriedem: ya. that was one of the open questions should nova claim the bandwith or tell neutron to do it as part of port bining which we want to move to condutor | |
| 16:41:17 | mriedem | port binding was never moving to conductor | |
| 16:41:17 | efried | mriedem: Sure: we're polling the SSP to get available capacity for inventory reporting. If that changes (disk is added, disk goes offline, cluster node tanks, whatever), we want to modify the SSP's inventory accordingly. In this example, whichever virt gets there first, wins. | |
| 16:41:20 | mriedem | port creation was moving to conductor | |
| 16:41:30 | sean-k-mooney | mriedem: it was as part of the multi port binding spec | |
| 16:41:37 | jaypipes | sean-k-mooney: port binding != resource allocation. I'd rather have the conductor do the resource allocation steps than the nova-compute during port-binding | |
| 16:42:21 | mriedem | jaypipes: agree, otherwise we have a late claim on the wrong host and we fail | |
| 16:42:27 | sean-k-mooney | jaypipes: today yes port-binding happens on compute but intent is for it to move to conductor before we call the compute node | |
| 16:42:34 | jaypipes | mriedem: and we're back to square one again. | |
| 16:42:44 | mriedem | sean-k-mooney: i don't remember ever talking about moving port binding to conductor | |
| 16:42:50 | sean-k-mooney | let me see if i can get the relevent part of the spec | |
| 16:42:59 | mriedem | in the long ago, johnthetubaguy was working on moving port *creation* to conductor | |
| 16:43:07 | efried | To cdent's point, would y'all be on board with imposing a restriction in the code that MISC_SHARES_VIA_AGGREGATE and tree-ness are mutually exclusive? | |
| 16:43:15 | jaypipes | mriedem: and that is resource allocation, not port binding... | |
| 16:43:34 | johnthetubaguy | s/nodes/nods/ | |
| 16:43:38 | efried | Freudian slip ^ :) | |
| 16:43:45 | johnthetubaguy | :) | |
| 16:43:47 | jaypipes | efried: I don't really see the need, frankly... | |
| 16:43:50 | cdent | efried: I think it's probably okay to not enforce it. just don't got parent or child hunting in u_p_t | |
| 16:44:00 | mriedem | jaypipes: port creation is resource allocation? in what way? | |
| 16:44:03 | mriedem | besides quota | |
| 16:44:08 | efried | jaypipes: It's not a *need* per se; would just allow us to kick this can down the road. | |
| 16:44:14 | jaypipes | efried: just don't ever search deeper than a single node level for any sharing providers | |
| 16:44:21 | johnthetubaguy | it was nice for case where you pick the correct IP segment for routed networks | |
| 16:44:40 | johnthetubaguy | where placement deals with the IP resources, that may be limited in the case of public ones | |
| 16:44:41 | jaypipes | mriedem: what johnthetubaguy said. | |
| 16:45:04 | jaypipes | mriedem: but it's not important right now. | |
| 16:45:28 | jaypipes | mriedem: I would be fine just mandating that sharing provider information gathering never exceeds the single level of the sharing provider. | |
| 16:45:34 | sean-k-mooney | mriedem: jaypipes https://git.openstack.org/cgit/openstack/nova-specs/tree/specs/queens/approved/neutron-new-port-binding-api.rst#n139 | |
| 16:45:36 | efried | jaypipes: Okay, but do we include the sharing provider's whole tree or not? | |
| 16:45:44 | mriedem | efried: i'd say no | |
| 16:46:01 | cdent | no | |
| 16:46:02 | efried | I'm worried about the future impact of spoofing a child as a root | |