On Tue, Jun 28, 2016 at 8:54 PM, Lars Marowsky-Bree <lmb@xxxxxxxx> wrote: > Hi all, > > silly question time. From a UX perspective, we sometimes need to know > what a specific pool does. We can't always figure it out directly by > looking at the pool - is this used for RBDs? A MDS metadata pool? RGW > buckets? > > Right now, that is all bundled into the naming scheme. Is that the way > to proceed? Is there a recommended/standard naming scheme that tools > could attach to, then? > > We though of storing it in an object in the pool, but, uh, that > obviously doesn't work so well for cache-tiered pools ;-) > > Or should we have metadata about our Ceph entities maintained outside > Ceph, in a separate tooling database? > > Or would there be the chance to somehow store some description > somewhere, like a few k/v, free-form? x-... parameters maybe? > > (Tool suppliers could then agree on common tags, hopefully.) I've had some thoughts along these lines -- I was thinking it would be nice to have tags on auth IDs so that one could for example save the mapping between the Ceph ID and something outside of ceph. As Greg mentions, we have the "config-key" interface currently, but it would be kind of nice to be able to do it in a more structured way. Storing "extras" without bloating the cluster maps is definitely not a problem, we do this for the OSD metadata, the awkward part is just keeping it all in sync, making sure things get cleaned up when pools/osds/keys go away. While there is clearly a limit somewhere to how much non-essential state we store via the mons, my feeling is that we should go at least a bit further than our current config-key interface. What about something like namespacing those keys into a path-ish form like "[pool|osd|rule].<id>"? We could potentially do smart things with those well-formed keys down the line, like ensuring they correspond to things that really exist, including them in certain outputs, and enabling people to efficient scoped operations like "config-key list pool.3.*". 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
