Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-18
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:
16:42:03 efried - s/ensure/additional/g
16:42:03 efried - forward compat for $minor version (additionalProperties:true)
16:42:03 efried - $COMPUTE_NODE with explanation that includes "all ironic nodes"
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?
16:53:54 dansmith well, I really think allowing them to remove traits by this mechanism is dangerous, as I said
16:53:56 sean-k-mooney efried: my perfernce would be that the behavior would be the same regardless of the virt driver if at all possible
16:54:02 dansmith yes ^
16:54:17 cdent is there any mechanism to remove traits?
16:54:21 efried In this iteration only adding traits is allowed, so the difference is whether, when I try to add a trait that's otherwise dealt with by the compute manager, it sticks or not.
16:54:38 efried cdent: not yet, but we've been trying to leave it open for that possibility (in some form) in the future.
16:54:39 dansmith definitely should not
16:54:48 efried okay.
16:54:49 efried so
16:54:50 sean-k-mooney if we allw modifcation of inventores/traits creted by the virt driver i also conceed we might want to delgate processign to the virt driver at that point
16:55:05 dansmith efried: don't we have a declaration of which traits are owned by the compute and virt, so that we can wholly box off those anyway?
16:55:17 efried today: update_provider_tree => update_auto_traits
16:55:17 efried tomorrow: update_provider_tree => process_providers_yaml => update_auto_traits
16:55:24 efried dansmith: no, unfortunately not
16:55:38 efried and in fact, the above mixes poorly
16:55:38 sean-k-mooney dansmith: not really. unless we say provdier.yaml can only use CUSTOM_
16:55:40 dansmith efried: well, maybe we should do that as part of this.. I know we discussed it before
16:55:44 sean-k-mooney which i think is too restrictive
16:55:51 dansmith sean-k-mooney: well, that would probably not be too bad, IMHO
16:55:54 efried because update_provider_tree may have some traits it enforces
16:56:13 dansmith it would clearly draw a box around the things you're doing as being purely localized customization and not mucking with internal features
16:56:20 efried but then update_auto_traits (which is not under control of the virt driver -- except as declared by the compute capabilities dict) has others
16:56:21 sean-k-mooney it would be nice to be able to use a standard hyper treading treat or secure boot trait
16:56:33 sean-k-mooney and use the file to add them if its supported
16:56:42 efried dansmith: unfortunately it's not easy to do. See venn diagram here https://docs.openstack.org/nova/latest/reference/update-provider-tree.html#taxonomy-of-traits-and-capabilities
16:56:57 dansmith sean-k-mooney: but why would that not be exposed by the driver if it's available and enabled? making operators track that is dumb
16:57:03 sean-k-mooney im not sure if those are actully good examples

Earlier   Later