volume: provide an option to set a 'tag'

[amarts]

... (or many tags) on a volume while creating (or with volume update apis).

This tag can be used to display reduced set of volumes, like

gluster volume info --tag=something

If we get each different layer integrating the API to set their own tag while creating the volume, it would be very useful for debug, analytics (like which tool is actually creating more volumes etc).

To start with we can mark everything going in with cli as tag:'cli'.

@JohnStrunk (add more if something is missed)

[atinmu]

So this can be an option in the volume create request API and then 'gluster volume info --tag=something' can filter this out. Is this what the requirement is? If yes, this should be quite easy to implement. Need a change in volume create & volume info (ReST APIs and CLI commands)

[atinmu]

Checklist

• ReST APIs availibility in wiki
• CLI commands
• Sufficient logging
• Availibility of metrics data if applicable
• Xlator options table upto date?
• Test cases & test coverage of the functionality

[JohnStrunk]

To clarify my original intent with this feature: I'm looking for the ability to store additional metadata with gluster entities that are exposed externally (e.g., volumes, nodes, clusters, snapshots). If devices/bricks are exposed, they should be taggable also.
My use case is for external tools to tag entities that they are managing, both for loosely registering ownership as well as storing configuration information. For example, a kube provisioner might tag a volume with information such as:

• owner = kube-gluster-subvol <== this volume is being used for subdir-based PVs
• overcommit = 2.0 <== the provisioner will hand out PVs with quota totaling 2x the capacity of the volume
• max-subvols = 5000 <== the provisioner will put a max of 5000 subdir-based PVs on this volume.

The above are just examples of how I could see this being used. glusterd should not interpret these tags in any way other than to allow filtering as @amarts showed above.

[prashanthpai]

It's in the plan to allow custom metadata (key/value pairs) for peer and volume objects. Core glusterd shall not interpret or use these in any way. However, glusterd2 will impose a size (in bytes) restriction.

[prashanthpai]

@vpandey-RH Checklist:

• Add volume edit REST API
• Add CLI support
• Add support to delete metadata keys

[prashanthpai]

@vpandey-RH Next step would be to add support to list volumes that have specific keys and/or values set. You can extend the existing volume list API by adding query params.

[prashanthpai]

@vpandey-RH

The documentation formatting needs to be fixed.

[vpandey-RH]

@prashanthpai Resolved the documentation issue