On Wed, 23 Oct 2019, Sebastian Wagner wrote:
- The 'name' here, IIUC, is the name of the grouping of daemons. I think it was intended to be a file system, as per the docs:
The ``name`` parameter is an identifier of the group of instances:
* a CephFS file system for a group of MDS daemons, * a zone name for a group of RGWs
but IIRC the new CephFS behavior is that all standby daemons go into the same pool and are doled out to file systems that need them arbitrarily.
We use this to set the name of the Rook CR, and this is afaik still supposed to be the fs name.
Patrick: this will be confusing the rook case too, right? Imagine two CephFileSystem CRs, each saying 3 mds daemons, but in reality the pool of 6 MDSs will be assigned randomly-ish to either fs?
- For SSH, none of that works, since we need to pass a location when adding daemons. It seems like we want somethign closer to nfs_add, which is
@_write_cli('orchestrator nfs add', "name=svc_arg,type=CephString " "name=pool,type=CephString " "name=namespace,type=CephString,req=false", 'Create an NFS service')
i.e.,
* 'add' takes a 'name' (the actual daemon name) and a location (if the orch needs it).
You could add a field `hosts` to PlacementSpec of type `List[str]`. We need this for all stateless services for the ssh orch anyway. Let's add it now.
In this case, we should add a count arg, and svg_arg is... a subvolume name?
* 'rm' takes the same name and removes it.
Yes
* 'update' does the smarts of adding ($want - $have) daemons for a given group and generating names for them. Something else organizes these into groups (a common name prefix?). I.e., 'update' basically builds on 'add' and 'rm'.
add creates a completely new "service" (aka group of physical daemons). Update is supposed to add and remove daemons from this service. `update` is not supposed to call add or rm.
`add` creates a new "group of daemons" (aka "service") `rm` removes the whole group of daemons `update` deploys new daemons to an existing group.
Okay, this makes sense. In that case, the name should presumably be a prefix, and the daemon names should get a numeric (or random string) suffix. I'll go with that for now, and ignore the sharing of MDS daemons for the moment... sage
And/or, we introduce some basic scheduling into ssh orchestrator (or orchestrator_cli). I'm not sure this is actually that smart since we can probably get away with something quite simple: round-robin assignment of daemons to hosts,
I'd be +1 for keeping the deployment 100% predictable at this time.
and the ability to label nodes for a daemon type or daemon type + grouping. This would basically give ssh orch what ansible does as far as mapping out the deployment, and gracefully degrade to something that "just works" (well enough) when you don't know/care where things land. Obviously having a real scheduler like that in k8s do this is better, but for non-kube deployments, there is still a need for placing daemons to hosts to make things easy for the human operator.
I'm not yet into pros, cons and use cases of different low level scheduling mechanisms.
sage
-- SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg)