Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-18
16:16:03 dansmith I'm not sure what you mean about the explicit operator tasks
16:16:11 sean-k-mooney efried: in v1 of this are we going to allow the provider yaml to modify any RP create by the virt dirver. i read the last version fo the spec as no. we would only beable to add new rps as childern of the copute node
16:16:15 efried I get the parallel with nova.conf, where you can put in all the [foo]bar=baz you want and it'll get ignored by the code. But that's an artifact of oslo.config - we couldn't do anything about that if we tried.
16:16:22 dansmith you mean because you made them put the minor in there?
16:16:44 sean-k-mooney efried: well we could
16:16:58 sean-k-mooney we know all the valid filed we coudl check for any that are not registered
16:17:03 sean-k-mooney and raise an error
16:17:05 sean-k-mooney we just dont
16:17:14 efried dansmith: In both cases I'm assuming a file with schema_version:1.5 and some 1.5-specific values therein.
16:17:15 dansmith sean-k-mooney: we're talking about the opposite thing, and he's right we can't check for that
16:18:01 sean-k-mooney we cant check for fileds and section in the config we dont have a config option registered for?
16:18:12 sean-k-mooney that seams like ti would be pretty trivail to do
16:18:12 efried dansmith: in the stricter impl (as proposed), if compute is at 1.4, it will fail.
16:18:12 efried in the looser impl (what you're suggesting), if compute is at 1.4, it will successfully load up the config, but only process the >=1.4-isms, ignoring the 1.5-isms.
16:18:24 dansmith sean-k-mooney: can you hold on a sec, we're not even talking about the actual config file
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 okay, so:

Earlier   Later