On Wed, Jul 25, 2018 at 8:29 PM Patrick Donnelly <pdonnell@xxxxxxxxxx> wrote:
>
> On Wed, Jul 25, 2018 at 8:45 AM, Sage Weil <sweil@xxxxxxxxxx> wrote:
> > Some of the container-based deployment scenarios bind-mount /var/run (or
> > /run these days?) to the host's /var/run. This allows admin
> > socket scrapers to run once on the host for all containers. (I'm not sure
> > if there are other motivations for doing this.)
> >
> > In order for that to work, we need to make sure the asok files don't
> > collide (e.g., two osd.0's on the host in different clusters/containers
> > both trying to use /var/run/ceph/ceph-osd.0.asok).
> >
> > Ideally, I think, there would be a 'container id' that is unique for each
> > container on the host that could be used in the admin_socket config option
> > specifying the filename. Does such a thing exist?
> >
> > Seb also mentioned
> >
> >> On docker only this works:
> >>
> >> [root@ceph-nano-lul-faa32aebf00b /]# awk -F '/' '/:memory:\/docker/ \
> >> {print $3}' /proc/self/cgroup
> >> b80d7e22a089348498710e11be333dd97ed31c000e914ebc03da2b3a76a0aca6
> >
> > but that seems less than ideal.
>
> Instead of relying on system metadata, perhaps we could use the
> instance id? That would require first setting up a MonClient. Maybe
> that's acceptable?
If our underlying motivation is just to avoid two "osd.0" containers
having colliding admin sockets, then I wonder if the extra unique ID
in the filename needs to be meaningful at all? Presumably from an
admin socket scraper's point of view, they're not going to make sense
of the container ID (or the monc instance id, if we used that).
Or, if multi-cluster is the motivation, perhaps we could just use the FSID?
John
>
> --
> Patrick Donnelly
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
