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)
>
> _______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
