| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-12 | |||
| 18:32:17 | sean-k-mooney | efried: for a shared storage pool nova does not really own that RP cinder likely does | |
| 18:32:40 | efried | sean-k-mooney: Sometimes. PowerVM SSPs will be (co-)owned by the virt driver(s). | |
| 18:32:44 | dansmith | efried: well, I agree the virt driver can draw its own aggregates around things and manage those itself, and maybe tell compute that it should join an aggregate for some shared storage it's connected to, | |
| 18:32:54 | dansmith | but nothing more authoritative than that | |
| 18:34:01 | efried | dansmith: In which case we need to amend the u_p_t charter for aggregates in the same way we just did for traits. Because as currently designed, virt just overwrites the aggregates. | |
| 18:34:29 | dansmith | efried: okay I'm not sure how that was ever considered a reasonable thing to do, but.. yes, agree it needs to not do that :) | |
| 18:34:53 | efried | And we have the same quandary as to which aggregates the virt driver "owns", so it knows which ones to de-assert. | |
| 18:35:05 | sean-k-mooney | efried: this feels like a case of placement is used almost entirely by nova today and we need to make it support other services. | |
| 18:35:16 | efried | And I contend that that's a much stickier problem than the traits one. Because we don't have a static list of agg UUIDs that virt "might" use. | |
| 18:35:27 | sean-k-mooney | efried: that said we should have hit this already with routed networks in neutron | |
| 18:35:35 | dansmith | efried: okay, I guess I'm surprised that aggregate membership is part of provider tree, but fair eough | |
| 18:35:52 | efried | sean-k-mooney: We're not talking about changing anything on the placement side. Just nova's consumption thereof. | |
| 18:36:02 | dansmith | efried: right, if it's doing that, then it's going to need some persistence to keep track of which ones it has created | |
| 18:36:16 | dansmith | sean-k-mooney: right his point is that we need to not be so aggressive in nova, | |
| 18:36:21 | dansmith | er, efried : | |
| 18:36:31 | dansmith | because we can't trample what other users would have done, human or otherwise | |
| 18:36:34 | sean-k-mooney | efried: yes but neutron is modeling routed netwoks in placement today using aggreagtes to express what node can connet to routed subnets correct? | |
| 18:37:39 | efried | I don't know that answer. (But probably not "today" if you mean "code that's merged".) | |
| 18:37:53 | dansmith | it doesn't matter, | |
| 18:37:57 | dansmith | that's a thing that will happen | |
| 18:38:00 | dansmith | neutron, cinder, et al | |
| 18:38:17 | sean-k-mooney | efried: well neutorn has been tracking routed network in placement since pike i think | |
| 18:38:53 | efried | sean-k-mooney: By creating placement aggregates around compute node resource providers? | |
| 18:39:20 | sean-k-mooney | efried: i think so im currently checking | |
| 18:39:47 | dansmith | it doesn't matter, that's a thing we must support | |
| 18:39:53 | jaypipes | efried: how about just relaxing the aggregate overwrite thing to instead just add aggregates (and potentially remove aggregates that the virt driver is 100% sure it owns fully)? | |
| 18:40:40 | efried | jaypipes: Which is exactly what we're doing for traits. The difference is that knowing that second thing is way harder for aggs. | |
| 18:41:56 | efried | jaypipes: Kinda one step harder than the trait thing will be for the ironic case... | |
| 18:42:01 | jaypipes | efried: if the virt driver created the agg, then it knows that, no? | |
| 18:42:06 | efried | jaypipes: No. | |
| 18:42:14 | efried | jaypipes: u_p_t has no memory. | |
| 18:42:29 | jaypipes | efried: right, but the virt driver could persist that data somewhere itself.. | |
| 18:42:51 | efried | jaypipes: Would have to be a file; else this doesn't work across compute restarts. | |
| 18:43:08 | efried | Are we in the practice of letting virt drivers write arbitrary files?? | |
| 18:43:48 | jaypipes | efried: IMHO, the virt drivers can do whatever they want w.r.t. persisting local information. | |
| 18:44:02 | efried | eek | |
| 18:44:03 | jaypipes | efried: hell, that's pretty much what the libvirt XML files are ;) | |
| 18:44:04 | cdent | except write allocations! ) | |
| 18:44:09 | dansmith | well, | |
| 18:44:13 | jaypipes | cdent: well... good point :) | |
| 18:44:23 | dansmith | anything we do in that regard has to *really* be sure that it supports upgrade properly, | |
| 18:44:28 | dansmith | and we don't have a lot of tooling around that | |
| 18:44:49 | dansmith | so I would be hesitant to approve any new things around that without a plan | |
| 18:45:02 | dansmith | right now, all the data we store is managed by nova and tested (to the limit it's possible) by our upgrade tooling | |
| 18:45:04 | jaypipes | dansmith: agreed. but, if powervm wants to use etcd running on a mainframe in a datacenter in Cambodia, I honestly couldn't care less. :) | |
| 18:45:10 | sean-k-mooney | efried: this covers the aggregate usecase for neutron reouted networks. https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/neutron-routed-networks.html#proposed-change | |
| 18:45:30 | dansmith | jaypipes: well, I care, because I care about users' experience with nova being positive when possible | |
| 18:45:39 | sean-k-mooney | efried: the first paragrph directly covers the use of aggregated to model network segments | |
| 18:45:43 | dansmith | jaypipes: which is why I care about virt drivers merging random crap that affects that view | |
| 18:45:44 | jaypipes | dansmith: I, of course, *would* care about the libvirt driver doing such a thing. | |
| 18:46:24 | dansmith | jaypipes: it's hard to explain why we hold libvirt to a different standard once we let things like that into other drivers, but anyway.. | |
| 18:46:40 | jaypipes | fair enough. | |
| 18:47:48 | sean-k-mooney | jaypipes: well libvirt xmls are generated at runtime so they are not really persiting state | |
| 18:48:11 | sean-k-mooney | jaypipes: we can recompute them form info in the nova db if they were deleted | |
| 18:48:16 | dansmith | sean-k-mooney: their compatibility is also managed by libvirt | |
| 18:49:35 | sean-k-mooney | dansmith: yes that too. we did discuss brefily that we could add a table to the nova db for virt dirvers to store instance specific info. provided we used ovo or something similar to version the data they stored for upgrades | |
| 18:50:08 | dansmith | yep, that would be better from an upgrade point of view | |
| 18:50:44 | sean-k-mooney | in this case we would have to simple presetit a list of virt_driver owned aggregats or something along those lines? | |
| 18:52:12 | sean-k-mooney | personally i dislike storing json blobs in the db but if its somting we will never query against and is just used as a keyvalue store for the virt dirver then as long as its versioned in some way i personally dont care as much | |
| 18:52:23 | dansmith | that's pretty specific to this case | |
| 18:52:49 | dansmith | I'm not opposed to virt drivers storing things locally, I just think we need a plan to avoid letting it get out of hand and breaking during an upgrade | |
| 18:54:37 | jaypipes | dansmith: I don't disagree with you. I was being a bit tongue in cheek earlier about the datacenter in Cambodia. | |
| 19:05:13 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Support default allocation ratios https://review.openstack.org/552105 | |
| 19:06:59 | cfriesen | dansmith: as per discussion at PTG: https://bugs.launchpad.net/nova/+bug/1754782 I won't have any time to work on it till next week at the earliest. | |
| 19:07:00 | openstack | Launchpad bug 1754782 in OpenStack Compute (nova) "we skip critical scheduler filters when forcing the host on instance boot" [Undecided,New] | |
| 19:13:42 | melwitt | jaypipes: thanks for writing up the PTG summary for placement, good stuff | |
| 19:14:30 | jaypipes | melwitt: no prob. thanks to mriedem and gibi who double-checked stuff on it. | |
| 19:14:57 | melwitt | mriedem++ gibi++ | |
| 19:16:20 | sean-k-mooney | QQ just working on https://bugs.launchpad.net/nova/+bug/1747496 did we remove the old default config values from MTU when not set on the port from nova? i think we did but just setting | |
| 19:16:21 | openstack | Launchpad bug 1747496 in OpenStack Compute (nova) "MTUs are not set for VIFs if using kernel ovs + hybrid plug = false" [Medium,Confirmed] - Assigned to sean mooney (sean-k-mooney) | |
| 19:16:25 | sean-k-mooney | *checking | |
| 19:20:23 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Allow for merging traits https://review.openstack.org/552122 | |
| 19:20:34 | efried | dansmith, jaypipes, cdent, sean-k-mooney, edleafe: ^ | |
| 19:20:40 | sean-k-mooney | hum it does appare to be in https://github.com/openstack/nova/blob/master/nova/conf/network.py or in .../neutron.py so i guess they are gone and were move to os-vif https://github.com/openstack/os-vif/search?utf8=%E2%9C%93&q=network_device_mtu&type= | |
| 19:20:46 | efried | I didn't make any changes for aggregates. | |
| 19:21:01 | cdent | efried: thanks, in the queue | |
| 19:23:02 | sean-k-mooney | efried: im just heading home but i addem myself to the review and ill leave it open in a tab for tomorow. ill give it a quick skim before i leave however | |
| 19:24:18 | dansmith | efried: looks okay to me | |
| 19:25:46 | sean-k-mooney | efried: why did you start with "Traits are special. Rather than overwriting the entire set of traits" this statement also applies to RPs and Aggregates | |
| 19:26:17 | efried | sean-k-mooney: Because I wrote this before it occurred to me that we should be doing the same for the other bits. | |
| 19:26:21 | sean-k-mooney | efried: the compute node RP is not owned by nova so nova cant override all child RPs of the compute node either | |
| 19:26:29 | sean-k-mooney | efried: ah ok | |
| 19:26:51 | efried | sean-k-mooney: But I also wanted to do this one isolated because I don't think we're done discussing the others. | |
| 19:27:07 | efried | The compute node RP *is* owned by nova. | |
| 19:27:24 | efried | sean-k-mooney: And *some* of its children may also be. | |
| 19:27:51 | dansmith | yeah, the compute node RP is _definitely_ owned by nova :) | |
| 19:28:05 | efried | In general virt needs to be smart enough not to muck with stuff it doesn't own. But originally we *thought* that meant virt owns everything about the RPs it owns. | |
| 19:28:07 | sean-k-mooney | efried: that has issues wich other services want to tag it with traits | |
| 19:28:08 | dansmith | agreed nova can't blow away all the providers underneath, unless it's deleting the compute node | |
| 19:28:28 | sean-k-mooney | dansmith: well event then i dont think it can | |
| 19:28:36 | efried | Which is why we already have ProviderTree methods to add/remove providers in the tree. | |
| 19:28:42 | efried | ...individually. | |
| 19:28:49 | dansmith | sean-k-mooney: it has to be able to delete it and the subtree, IMHO | |
| 19:29:44 | sean-k-mooney | dansmith: if i have a converged deployment where my compute nodes are also cinder storage pool providers the the root node of the tree would be a parent of the nova resources and the cinder resouces | |
| 19:29:52 | efried | Agree. E.g. if neutron created bandwidth RPs under a PF, and compute removes the PF, the bandwidth providers are no longer relevant. | |
| 19:30:05 | sean-k-mooney | which is why i dont think the root node can be owned by nova | |
| 19:30:14 | efried | sean-k-mooney: I don't think that's a model we should support. | |
| 19:30:16 | dansmith | sean-k-mooney: in that case the cinder providers are not servicing other computes, right? then it's okay to delete it | |
| 19:30:28 | dansmith | sean-k-mooney: if they are servicing others, then the cinder pool should not be a child of the compute node | |
| 19:30:45 | sean-k-mooney | dansmith: no the could be and associated with other computes via a sharing aggregate | |