> Op 28 juni 2016 om 23:20 schreef John Spray <jspray@xxxxxxxxxx>: > > > 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. > That would be awesome. Being able to tag a OSD with for example: bluestore,nvme,ssd,hdd You could query these tags again and have automation to stuff around it. Or also start a OSD: $ ceph-osd --id 0 --tags ssd,bluestore The tags could then be used by additional tools to query stuff from there. > 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 -- 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
