| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-12 | |||
| 17:50:17 | sean-k-mooney | efried: they get to create new ones. not sure they are allowed to modify existing ones | |
| 17:50:38 | efried | sean-k-mooney: Then we have exactly the same problem - how does the virt driver know it gets to remove an aggregate association? | |
| 17:51:07 | sean-k-mooney | it cant unless it created it | |
| 17:51:34 | sean-k-mooney | other service can create aggregates also not just the operator | |
| 17:52:54 | arvindn05 | mriedem: https://review.openstack.org/#/c/541507/ - can you take a look at the latest patchset? I think it should address your concerns | |
| 18:04:48 | openstackgerrit | Hongbin Lu proposed openstack/nova master: Skip placement on rebuild in same host https://review.openstack.org/546357 | |
| 18:06:44 | efried | I don't suppose there's a way to permalink an etherpad line | |
| 18:07:42 | sean-k-mooney | efried: i dont think the lines have css id so no | |
| 18:08:02 | efried | sean-k-mooney: Or even permalink the etherpad as a whole at a point-in-time. | |
| 18:08:30 | edmondsw | efried I wouldn't think so | |
| 18:08:34 | sean-k-mooney | efried: you could use http://archive.org/web/ | |
| 18:08:53 | efried | mmm, nice | |
| 18:09:11 | sean-k-mooney | efried: make a snap shot of the doc then link to the snap shot and give the line number | |
| 18:09:47 | efried | sean-k-mooney: Yeah, I'll pastebin just the relevant section. | |
| 18:09:51 | efried | I guess. | |
| 18:11:39 | sean-k-mooney | efried: you can create readonly share links in etherpad like this one https://etherpad.openstack.org/p/r.2bb9e3053658b6ddf5e73d31045dcfba | |
| 18:13:07 | efried | sean-k-mooney: That doesn't actually freeze it. Just makes it so you can't edit. | |
| 18:13:16 | efried | sean-k-mooney: Changes still show up. | |
| 18:14:06 | sean-k-mooney | efried: ah ok ya maybe with the version specified https://etherpad.openstack.org/p/r.2bb9e3053658b6ddf5e73d31045dcfba/timeslider#43302 | |
| 18:14:15 | sean-k-mooney | still pastbin might be cleaner | |
| 18:14:24 | efried | aha, #timeslider is probably what I want. | |
| 18:14:55 | efried | 'cept no line numbers! | |
| 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 | |