mon-osd separation fixes. making netplugin optional for service_worker #108
Conversation
|
|
||
| # OSDs could be run without netplugin on them | ||
| # osd_contiv_network_include controls this behaviour | ||
| osd_contiv_network_include: "true" |
There was a problem hiding this comment.
I am presuming we will need multiple such variables based on host capabilities viz. compute only; storage only; with compute and storage) so instead of defining ceph specific boolean variables I feel it is better to introduce a single variable like say host-capability of type enum with possible values like compute-only, storage-only, compute-and-storage and use that in the conditionals below to include the roles in various host-group, something like when: host_capability | match(*storage*)
This offers the benefit of cutting down on the number of variables we need and also keeps it independent of ceph as we may support different storage types in future and same host-cpabilities will apply. WDYT?
There was a problem hiding this comment.
@mapuri.. yes, consolidating under a common var would be good. But I think we should specify exclusion. So, everything is included by default, unless an exclusion is specified. for example the below would specify not to run mon and osd on the given host. It can be one large string of comma separated values.
host-capability => “not_mon, not_osd"
when: host-capability | match(*not_osd*)
There was a problem hiding this comment.
well negation is kind of hard to read... also instead of mon and osd being capabilities I prefer more generic capabilities like compute and storage..mon and osd makes it specific to ceph and we will need something similar if we were to do NFS based storage on UCS B-series servers
There was a problem hiding this comment.
just to add if we really need negation it might be better achieved using logical operator so a node with no storage capability can matched using this condition when: ! host-capability | match(*storage*)
There was a problem hiding this comment.
@mapuri yes, I agree that negation is hard to read, but the flip side is that the user needs to specify every capability he wants on the node.
on the topic of keeping it to storage and not getting down to mon/osd. Is there a case, a host might want to run both ceph and nfs on the same node. wondering to what level should the capability be defined - being able to do nfs based storage is a capability. being able to do ceph storage is another capability. so, do you think specifying "Storage-node" is good enough?
There was a problem hiding this comment.
but the flip side is that the user needs to specify every capability he wants on the node.
hmm, yeah, it is a problem if we have too many capabilities. How about we set host-capability to default as compute,storage and then let user override it to specific values? Again this is only a problem if we have too many capabilities. Another way to deal with this (when we have a lot of properties) would be to give a short-hand/pre-defined variables for common capabilities combinations. Say, for UCS B-series we can define a common-b-series-cap variable and set it to storage,cap1,cap2.... and users can instead use the short-hand strings instead?
on the topic of keeping it to storage and not getting down to mon/osd. Is there a case, a host might want to run both ceph and nfs on the same node....
so, do you think specifying "Storage-node" is good enough?
Franky I don't know. But from what we have in contiv_network, I think in a contiv-cluster it will be either ceph or nfs but not a mix, so storage should good enough. And the differentiation of starting right set of storage daemons might be better made at the contiv_storage role (like we do for contiv_network to deploy netplugin in either aci, or standalone or bgp mode).
But to keep it extensible, may be storage-ceph is a better capability as you point out than just storage.
Signed-off-by: Vikrant Balyan <[email protected]>
|
@mapuri PTAL |
host capability checks for various roles
| - { role: scheduler_stack, run_as: master } | ||
| - { role: contiv_network, run_as: master } | ||
| #- { role: contiv_storage, run_as: master } |
There was a problem hiding this comment.
let's leave ceph* and contiv_storage roles commented out in these host-groups until #19 is fixed otherwise it breaks the commission/decommission workflows in cluster/master.
|
@vvb thanks for incorporating the |
|
@mapuri PTAL. the comments are taken care of. Is this good to merge now? |
|
LGTM, thanks @vvb |
mon-osd separation fixes. making netplugin optional for service_worker
statand registering the output to a variablesocket. When the task is skippedsocketis not what it needs to be. There are handlers that kick-in at the end of service-master workflow that depend onsocketto be correct. so, the correct solution is to do the stat when the handlers are fired, so that the true state is reflected.