| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-18 | |||
| 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 | |
| 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... | |