| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-12 | |||
| 18:14:59 | efried | gaaahhh! | |
| 18:16:28 | sean-k-mooney | efried: ya all the etherpads are version controled but yes the etherpad line number are added with javascipt renderer and are not part of the document | |
| 18:18:30 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Support default allocation ratios https://review.openstack.org/552105 | |
| 18:18:35 | jaypipes | dansmith: ^ | |
| 18:20:49 | dansmith | efried: I don't see the same problem with aggregates | |
| 18:20:59 | dansmith | efried: and aggregate changes wouldn't go through the compute service | |
| 18:21:08 | dansmith | efried: adds or removes would get mirrored to placement,m | |
| 18:21:26 | dansmith | but if the operator changed them in placement, we wouldn't necessarily un-do that with a sync based on what jaypipes has proposed as I understand it | |
| 18:23:29 | efried | dansmith: I think, as with the "driver capabilities" traits, the mirrored host aggregates will be a special case controlled by compute manager (!virt). But I mean in general. If an admin adds/removes an aggregate in placement directly, how does virt know not to remove/restore that aggregate association? | |
| 18:23:36 | sean-k-mooney | dansmith: i thikn efried main concern was how does nova know if it is allowed to remove a RP it created from an aggregate. my answer would be unless it created the aggregate it should not add or remove RPs from it | |
| 18:24:49 | dansmith | efried: the compute manager can't know what aggregate it's in | |
| 18:25:11 | dansmith | efried: it can't even access the database that has those details, nor talk to conductors that can | |
| 18:25:49 | efried | okay, sorry, "...special case controlled by conductor". But the point about the general case remains. | |
| 18:26:14 | dansmith | efried: I'm missing something | |
| 18:26:23 | efried | dansmith: I.e. do we need to implement ProviderTree.merge_aggregates ? | |
| 18:26:31 | dansmith | efried: at steady state, nova wouldn't add or remove providers from aggregates | |
| 18:26:32 | sean-k-mooney | efried: in the general case nova cant assume it own RPs or Aggregate in placement | |
| 18:26:41 | dansmith | sean-k-mooney: agree | |
| 18:26:45 | efried | sean-k-mooney: Disagree. Sigh. | |
| 18:27:25 | sean-k-mooney | efried: well the simple case would be that neutron may want to add compute nodes to a aggregate to model there availablity zones which do not have to map direclty to novas | |
| 18:27:33 | dansmith | efried: can you state that disagreement as a full statement? like, you disagree that... | |
| 18:27:38 | sean-k-mooney | same for cinder | |
| 18:27:43 | dansmith | sean-k-mooney: yep | |
| 18:27:56 | dansmith | sean-k-mooney: or the operator may do so for any other reason | |
| 18:28:25 | dansmith | efried: I just wonder which part you disagree with | |
| 18:28:27 | sean-k-mooney | dansmith: yes for failure domains suchs as power or ha failover or other usecse that openstck can discover | |
| 18:28:49 | dansmith | sean-k-mooney: yup | |
| 18:29:54 | sean-k-mooney | s/ can discover/ can't discover/ | |
| 18:29:56 | efried | The virt driver knows of a certain set of aggregates of which its providers (the ones it "owns") are members. What it does not necessarily know about is the set of aggregates of which its providers are *not* members. Today, as designed, u_p_t is supposed to just overwrite aggregate associations. So there's no affordance for outside agents to manipulate them. | |
| 18:30:30 | efried | The question is: do we need such affordance? At least for the host agg mirroring, it sounds like it. | |
| 18:30:49 | dansmith | efried: ah are you talking about an aggregate around a compute node and its children, for example? | |
| 18:30:59 | dansmith | efried: not equal to nova's host aggregates? | |
| 18:31:25 | sean-k-mooney | efried: yes we do for the neutron/cinder case and for failure domains. the virt driver should simple add/remove aggregates it owns but not overrite all aggregates for a RP | |
| 18:31:36 | dansmith | right | |
| 18:31:41 | efried | dansmith: Could be intra-tree; could also be inter-tree (e.g. a shared storage pool). The argument applies to the host agg mirrors as well as whatever else we want to do with aggs. | |
| 18:32:15 | efried | I.e. if the virt driver is not the single SoT for agg associations of the RPs it "owns", we have to have the exact same discussion as we just did with traits. | |
| 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. | |