[spec]Grouping nodes #42
Conversation
|
@gibizer This came across my path today and I was a bit confused why it exists. We have at least 3 or 4 google docs discussing architectural options for Dataplane services. Is this meant to be a consolidation of the Google docs perhaps and you only want comments here now? |
I'm trying to follow the pattern started in #31. Where after the initial discussion started to settle in the google docs the actual proposal is cleaned up and moved to this repo. This is intentionally in Draft state as I just finished writing this up as a cleanup of the google doc where the question / comments seems to be settled. I'm traveling this week. So this and #41 will remain in Draft state at least until next week. If you have comments feel free to provide it here or in the google docs (whichever is more convenient for you) in the meantime. I will sync things up next week and we can also chat about the way forward. |
|
/hold we need to land #41 first |
There was a problem hiding this comment.
note too other this is actully not part of this PR its inherited form #41 so we can ignore this file
| Each service operator that has EDPM specific service CRD (e.g. | ||
| NovaExternalCompute, OVNMetadataAgent) can define a Profile CRD (e.g. | ||
| ComputeProfile, NetworkProfile) to describe the service specific configuration | ||
| of a set of EDPM nodes. Then the human deployer can use annotations on the |
There was a problem hiding this comment.
I wonder if this is still too restrictive. The names used here suggest that there will be a single profile per operator, not per service. While I could imagine that e.g. NeutronOVNAgent may have a different scheme to map nodes to configuration from what NeutronSRIOVAgent perceives.
Of course, instead of a single NetworkProfile, we could have NeutronOVNAgentProfile and NeutronSRIOVAgentProfile. Even then, I wonder if there's space for a set of service specific profiles to be applied to a node.
(I am not ready to give a concrete example from Neutron or elsewhere for the scenario above, but I wonder if it would be wise to leave the interface slightly more generic, by using a set / list of profiles - global or per-service - as the interface here.)
(There may even be a scenario where the same profile makes sense for all services as a whole, e.g. for common oslo.* library configurations. You could e.g. mark a node with a "profile" called "Debug" and get all services deployed on the node configured with debug=True in their config files. Same for oslo.db and other tunings.)
There was a problem hiding this comment.
well the annotation and its type would technaily be up to the service operator to define
so if neutron wanted to support a list of profiles the neutron operator is free to do that.
we wanted to start with the simple case as for your node with both ovn and sriov you would create a thrid SRIOV_OVN profile that had the config for both.
granted that can lead to a large number of profiles if you need to multiple.
the current motivation to only having one profile si to avoid having to define any precedence relatantion or complex merging semantics. that does not mean the neutorn operator can support that we just didn't want to start from that state.
|
This is not applicable any more based on the decision that sevice-operators are should not run or trigger any ansible execution, and instead DataPlaneService CRs will do that. Such CRs forces to use DataPlaneRole for any kind of compute grouping. We might want to revisit the resulting Role explosion later. |
Depends-on: #41