| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-18 | |||
| 16:24:47 | dansmith | so you're generating the right version for the *Exact* code version you're deploying | |
| 16:27:06 | efried | I'm trying to convince myself that the extra restart is worse than my new fields being ignored, and I don't know why until I go figure out the version diff between the code and the config and which fields were added in that span. | |
| 16:27:23 | dansmith | it's not just the extra restart, | |
| 16:27:39 | dansmith | it's also the embedding of this knowledge into the ansible/puppet/whatever | |
| 16:27:57 | sean-k-mooney | we also might need to do reshapes right? | |
| 16:28:27 | dansmith | well, I guess I'd hope we don't, which is another reason for my other comment, | |
| 16:28:40 | dansmith | which is not allowing operators to randomly change/subtract inventory from what the virt driver is providing | |
| 16:28:51 | sean-k-mooney | im just thinking about FFU whould you have to start the compute agent for each version | |
| 16:29:00 | sean-k-mooney | or just do one config update at the end | |
| 16:29:17 | efried | we've removed all possibilities of reshape and affecting existing inventories from this version of the spec | |
| 16:29:28 | sean-k-mooney | e.g keep 1.2 all the way up to 1.5 cond and then update to 1.5 template or do you have to go lockstepp | |
| 16:29:51 | sean-k-mooney | efried: are you still allowing effect exiting RP | |
| 16:29:59 | efried | yes, but not existing *inventory* | |
| 16:30:00 | sean-k-mooney | by modifying tratis or adding new inventories | |
| 16:30:04 | efried | you can't muck with VCPU | |
| 16:30:31 | efried | and by "existing" I mean "inventories the virt driver deals with explicitly". | |
| 16:30:42 | sean-k-mooney | im not conviced we shoudl allow creating inventories or modifying tratis on the RPs created by the virt driver | |
| 16:30:45 | sean-k-mooney | at least in v1 | |
| 16:30:51 | efried | wait, what?? | |
| 16:30:54 | efried | That's the entire point | |
| 16:31:07 | sean-k-mooney | i was suggesting only allow creating child RP of the compute node | |
| 16:31:14 | efried | No | |
| 16:31:15 | sean-k-mooney | and giving you full contol of the RP | |
| 16:31:16 | efried | no child RPs | |
| 16:31:24 | efried | that is way more complex | |
| 16:31:33 | efried | and will be harder to "fix" in the future. | |
| 16:32:07 | sean-k-mooney | how have we solved the multi writer issue for the traits | |
| 16:32:32 | sean-k-mooney | e.g. traits taht are set to be ensured in the provider yaml vs auto discovered | |
| 16:32:34 | dansmith | sean-k-mooney: I mostly agree, but I understand why adding (and sometimes removing) traits will be necessary | |
| 16:32:37 | efried | As currently suggested, auto traits would still take precedence. Let me get you the spot where I explained that... | |
| 16:32:38 | dansmith | but totes agree on inventory | |
| 16:33:04 | efried | https://review.opendev.org/#/c/612497/12/specs/train/approved/provider-config-file.rst@159 | |
| 16:33:09 | dansmith | it's a slippery slope, | |
| 16:33:19 | dansmith | because you want them to be able to add/remove processor flag traits, | |
| 16:33:39 | dansmith | but if you let them remove things like the disabled trait, or something critical to the rest of nova, then they've broken the internals and don't know why | |
| 16:33:51 | dansmith | which is why I commented as such on the spec | |
| 16:34:01 | cdent | trait mgt is the part that has me most concerned/confused | |
| 16:34:27 | sean-k-mooney | right i was suggesting a seperate rp to avoid any possible conflcit with the virt driver | |
| 16:34:28 | efried | but this is why we've taken all that stuff out | |
| 16:35:05 | efried | the only thing that remains is the levels of hierarchy that would allow us to consider adding it back in the future without a major schema bump (or ugliness in the schema to work around that) | |
| 16:35:50 | efried | which (I think - I'm still trying to grok) is even more important if we want to ensure forward-compat of minor versions. | |
| 16:36:00 | efried | but | |
| 16:36:24 | efried | if it's going to be the difference between getting this moving and having it stuck | |
| 16:36:56 | efried | we can pare the schema down to only what's needed in v1.0 -- YAGNI+KISS | |
| 16:37:13 | dansmith | sean-k-mooney: so, I'm really glad to hear you object to the random editing of the inventory by this file, which energizes me to take a more rigid stand on that point | |
| 16:37:51 | efried | dansmith: we've already declared that you're not allowed to edit inventory of resources that the virt driver knows about. | |
| 16:38:15 | efried | (while noting that at some point in the future we want this file to be able to do just that for things like allocation ratios and reserved values) | |
| 16:38:26 | dansmith | efried: so then you can remove the "ensure" hierarchy level | |
| 16:39:07 | dansmith | I totally do not think this is the place to be controlling allocation ratios, and if it's in this file, it shouldn't be in the place where you expose other non-virt inventory | |
| 16:39:57 | dansmith | or change "ensure" to "add" or "additional" to make it clear that it's appending stuff | |
| 16:40:13 | dansmith | because I don't know how you're going to explain or communicate to people that try to override inventory in that section otherwise | |
| 16:40:19 | efried | we had "add" originally. | |
| 16:40:27 | dansmith | they're going to be like "dammit, I want to ENSURE that the VCPU inventory is 3" | |
| 16:40:34 | sean-k-mooney | right i was about to ask what does https://review.opendev.org/#/c/612497/12/specs/train/approved/provider-config-file.rst@197 actully do | |
| 16:40:35 | efried | gibi objected to that as being a verb and not idempotent | |
| 16:40:46 | dansmith | I think I did too, so... additional | |
| 16:40:51 | sean-k-mooney | i read that as only that trait will be reported | |
| 16:41:12 | sean-k-mooney | not ensure that trait is appended to the virt dirver set | |
| 16:41:21 | dansmith | yeah | |
| 16:42:03 | efried | - $COMPUTE_NODE with explanation that includes "all ironic nodes" | |
| 16:42:03 | efried | - forward compat for $minor version (additionalProperties:true) | |
| 16:42:03 | efried | - s/ensure/additional/g | |
| 16:42:03 | efried | okay, so: | |
| 16:42:06 | efried | what else? | |
| 16:42:23 | dansmith | not all ironic nodes, but all nodes | |
| 16:42:33 | dansmith | or "all nodes managed by this compute" or something like that | |
| 16:42:43 | sean-k-mooney | maybe call it $compute_service | |
| 16:43:19 | dansmith | GOD | |
| 16:43:21 | dansmith | no | |
| 16:43:28 | dansmith | have you read the comments from the last 24 hours? | |
| 16:43:36 | dansmith | it's *not* the service, it's the node that provides inventory | |
| 16:43:37 | sean-k-mooney | ok | |
| 16:43:39 | dansmith | that's the point :) | |
| 16:43:46 | sean-k-mooney | oh right | |
| 16:44:53 | sean-k-mooney | yes i was trying to say that i map node to a singel RP for a since server in my head. and that each ironci compute sevicce manage mulitpl phyical server each of which is a seper compute node but i think we mean the same thing and im jsut saying it badly | |
| 16:45:06 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP nova-next: Deploy noVNC from source https://review.opendev.org/671490 | |
| 16:45:26 | dansmith | sean-k-mooney: right, it's the terminology that is important I think, but obviously we're on the same page for mechanics | |
| 16:45:53 | dansmith | it would be wrong to apply something that is declared to be "for the compute service" to the "compute nodes" | |
| 16:46:10 | sean-k-mooney | yes | |
| 16:46:14 | dansmith | but making the terminology match makes it clear that it's for the node, 1, 2, or 20 of them as managed by this service | |
| 16:46:20 | efried | except we're conflating that a bit with things like the DISABLED trait... | |
| 16:46:55 | efried | perhaps that's not the best example, but we've got traits on the RP that are really capabilities of the compute service... | |
| 16:47:00 | dansmith | we're headed in the right direction with that though | |
| 16:47:06 | dansmith | disabled predates nodes as a concept | |
| 16:47:18 | dansmith | this moves it closer to the right thing, which is move it to the schedulable entity | |
| 16:48:11 | sean-k-mooney | well if a compute service was disabled. all the compute nodes it managed would be unavailable until ironci moved them to be managed by another compute service | |
| 16:48:31 | dansmith | that's my point | |
| 16:48:44 | dansmith | it used to be right, now it's wrong, disabled traits on compute nodes is making it right-er | |
| 16:49:05 | efried | also, do you feel as though the virt driver should or should *not* be involved in the processing here? | |
| 16:49:40 | efried | cdent: this plays into whether auto traits can be added or not | |
| 16:50:26 | efried | If we cut the virt driver out entirely, we can do the providers.yaml processing after update_provider_tree+update_traits without reorganizing the rt flow. | |
| 16:50:35 | sean-k-mooney | efried: we breifly discussed if the generic code should live in teh Resouce tracker or in the driver base class | |
| 16:50:59 | efried | Yeah, I'm less concerned about which module the generic code lives in and more about where it's invoked from in the flow. | |
| 16:51:32 | sean-k-mooney | right i have a prefence but im wondering what dansmith thinks | |
| 16:52:04 | efried | I've been proposing (https://review.opendev.org/#/c/612497/10/specs/train/approved/provider-config-file.rst@205) that it be invoked from within update_provider_tree itself, giving the driver a certain amount of control | |
| 16:52:14 | sean-k-mooney | also my perference change depening on what we allow in the current version and in the future | |
| 16:52:32 | dansmith | efried: remember, I was mostly concerned about the optics of how it's viewed from reading the spec, | |
| 16:52:42 | dansmith | but I do think that making it as absolutely uniform as possible is important, | |
| 16:53:08 | dansmith | and having it fully within the RT so that the RT refuses to update/replace anything the virt driver has done across the board would be the most consistent I think | |
| 16:53:26 | efried | including automatic traits? | |