| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-12 | |||
| 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 | |
| 19:30:58 | dansmith | sean-k-mooney: if they are, they should not be a child of the compute IMHO | |
| 19:31:20 | jaypipes | efried: I agree with both edleafe and dansmith on that update to the u-p-t spec | |
| 19:31:28 | dansmith | sean-k-mooney: the compute node RP is not the physical computer, it's the nova service and the hypervisor/virt driver underneath | |