On Wed, 5 Jun 2019, Gregory Farnum wrote: > On Tue, Jun 4, 2019 at 6:22 AM Jan Fajerski <jfajerski@xxxxxxxx> wrote: > > > > Hi list, > > I came across some strange MDS behaviour recently where it is not possible to > > start and MDS on a machine that happens to have the hostname "admin". > > > > This turns out to be this code > > https://github.com/ceph/ceph/blob/master/src/common/entity_name.cc#L128 that is > > called by ceph-mds here > > https://github.com/ceph/ceph/blob/master/src/ceph_mds.cc#L116. > > > > Together with the respective systemd unit file (passing "--id %i") this prevents > > starting an MDS on a machine witht he hostname admin. > > > > Is this just old code and chance or is there a reason behind this? The MDS is > > the only daemon doing that, though I did not check for other but similar checks > > in other daemons. > > There's a pretty funny trail of updates there, but it's still > basically what we see in the MDS code: it doesn't want to turn on if > it doesn't have a specified name. "admin" is the default (ie, > client.admin) and so the checker is incorrectly flagging it as being > unnamed when the name is derived from a host short name "admin". > > I'm not sure there's a good way to deal with that — we really *don't* > want somebody's misconfigured cluster to start up a bunch of MDSes > that all display as "mds.admin"! I think we probably want to change the behavior so that the default name is empty instead of admin, and the MDS refuses to start as 'mds.'. It means wading through some of the common/ and global/ code, which is always an adventure, but the same cleanup should apply to all of the non-client entity types (osd, mgr, mon, etc) too, so it should be time well spent! sage
