On Mon, Feb 19, 2018 at 5:28 PM, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > On Mon, Feb 19, 2018 at 7:27 AM, John Spray <jspray@xxxxxxxxxx> wrote: >> On Thu, Feb 15, 2018 at 6:52 PM, David Disseldorp <ddiss@xxxxxxx> wrote: >>> Hi Jeff, >>> >>> On Thu, 15 Feb 2018 13:09:45 -0500, Jeff Layton wrote: >>> >>>> IIUC, if the program (samba in this case) dies, and then is restarted >>>> (maybe host reboots?), it'll get a new instance_guid, right? Or am I >>>> misunderstanding what rados_get_instance_id will return here? >>> >>> Yes, that's right. On smbd restart it'll reconnect and get a new >>> instance ID. The hostname is carried in the metadata, which makes it a >>> little easier to identify what's going on from the Ceph side. >> >> As you say, the hostname is what most people are interested in most of >> the time anyway. >> >> Using a guid here will also going to be similar to what people see >> when running Ceph services in auto-scaled groups of Kubernetes >> containers -- lovingly hand-named daemons will be a thing of the past, >> and people will be dealing either with an ephemeral ID, or with the >> hostname from the metadata. >> >> The part where dead instances stick around in the status until they >> time out is annoying. In container environments we will need some >> logic for culling them when the container dies. In other environments >> we would either need to add the ability to do the explicit naming of >> the daemon, or just put up with the stale entries. > > You know, OSDs report to the monitor when they’re going down so that > their peers don’t need to wait through a timeout period. Should we > consider doing the same when a declared service shuts down? Yes, absolutely -- my head was stuck in the worst case (general case) path. Need a new shutdown message (or flag on one of the existing messages) and MgrClient should send it in ::shutdown if session && service_daemon. This will cause a little shutdown delay in librados, but I think it's acceptable as it's only for service_daemon users. http://tracker.ceph.com/issues/23042 John -- 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
