| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-18 | |||
| 16:18:43 | sean-k-mooney | sure sorry to interupt | |
| 16:19:14 | dansmith | efried: the operator should declare which "version of the docs" they're reading when they write the file, nova should not freak out about things it doesn't know about and not expect things to be present if the operator has clearly indicated they wrote the config file four versions ago | |
| 16:19:25 | dansmith | efried: the alternative is just to look at what is present in the file and not worry about the minor, and only use the major to control large changes, which I think we've already discussed | |
| 16:19:52 | sean-k-mooney | like the version in heat templates? | |
| 16:20:16 | dansmith | efried: but yes, all I'm saying is add additionalProperties:true, and just require the 1.5isms to not break the 1.4isms, and also not have compute fail if it expects 1.5 and only 1.4 is provided (which would break our upgrade promise, which has been in place since forever) | |
| 16:20:40 | dansmith | sean-k-mooney: is the heat template version a format version? I thought that was a self-assigned revision so heat can tell when you've modified it | |
| 16:20:48 | sean-k-mooney | yes | |
| 16:20:53 | sean-k-mooney | its the schema version | |
| 16:21:25 | dansmith | okay, then yes probably similar but I dunno what their semantics are | |
| 16:21:40 | sean-k-mooney | https://docs.openstack.org/heat/latest/template_guide/hot_spec.html | |
| 16:22:02 | sean-k-mooney | heat_template_version | |
| 16:22:03 | sean-k-mooney | This key with value 2013-05-23 (or a later date) indicates that the YAML document is a HOT template of the specified version. | |
| 16:22:08 | efried | dansmith: "1.5 schema and compute always accepts 1.4 config" -- absolutely | |
| 16:22:44 | efried | still don't agree with the other direction. | |
| 16:22:58 | dansmith | that 1.4 should be able to read a 1.5 file? | |
| 16:23:07 | efried | right. If I lay down a 1.5 file, I expect the 1.5-isms to be observed, not ignored. | |
| 16:23:21 | dansmith | so, here's how an upgrade has to go then: | |
| 16:23:23 | efried | noting that the file declares itself as 1.5 | |
| 16:23:30 | dansmith | 1. Start with 1.4 code and config everywhere | |
| 16:23:39 | dansmith | 2. Upgrade to 1.5 code over time | |
| 16:23:55 | dansmith | 3. Once all the 1.5 is deployed, then deploy 1.5 config everywhere, revisiting all nodes and restarting them again | |
| 16:24:20 | sean-k-mooney | Ignoring FFU is that not what we are ment to do in general | |
| 16:24:27 | efried | I see your point, you save the last restart if you do the loose way | |
| 16:24:33 | sean-k-mooney | e.g. upgade code then modify config after | |
| 16:24:37 | dansmith | or else you have to have two versions of all your ansible modules, or they have to embed the version awareness into the ansible modules | |
| 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 | |