Ceph » mgr » Dashboard

Jason Dillaman wrote:

The purpose for the application tags were to enable optimizations like this (i.e. we don't need to scan >>all the pools for an "rbd_directory" file). Your cluster should be in a health warn state if it has >>populated pools without an application tag associated with it. Also, at least the latest version of the >>dashboard allows you to manipulate the application tags. Therefore, if there is some confusion, perhaps >>we just need to add a pool drop-down selector to the table? The RBD pool drop-down already filters out >>non-RBD pools.

As per our conversation in daily standup meeting,

it is decided to go with the current behaviour and add a checkbox for showing all RBD images.

Why allowing dashboard users to take the wrong way? If pool app tags were created exactly for this purpose, the only thing a user has to do is properly tagging their pools as rbd (something that can be done from the dashboard itself).

By providing any 'tricky' checkbox, we are accustoming dashboard users to keep up with poor operating practices and overriding intended behaviours. If we fear most rbd users don't know about the need of tagging their rbd pools, let's add some warning message in case no rbd/rgw/cephfs is found due to missing tags.

And, btw, cluster would be on HEALTH_WARN due to pools without proper app tagging, so I think it's better to foster users towards HEALTH_OK clusters rather than providing work-arounds.

I'm also in for of adding some kind of help text to guide the user, instead of adding a checkbox that overrides the expected behavior.

I think the actual problem is that it's possible to add RBDs on the command line on pools that don't have the "rbd" application tag. The Dashboard already prevents that from happening by only offering Pools that have the appropriate tag. Maybe the CLI should abort with an error or print at least a warning message that the pool is missing the tag?

Related background information: https://ceph.com/community/new-luminous-pool-tags/