As an admin, i want to know which version of the product I am running. Can we perhaps install a file which contains the product version eg something equivalent to /etc/issue but in /etc/ceph on the admin node?)
We have multiple ways to figure this out. Would you please elaborate on the use case? Perhaps it is a matter of documentation?
So, ceph-the-CLI has a --version switch, as do all the daemons; ceph can also be used to dynamically query the version of a specific monitors or OSDs with commands 'ceph tell' and/or admin socket commands (because, of course, each daemon could be a different version). Also, there are versions of the packages installed available from the package manager. What precisely are we looking for?
Re-targeting to 2.0 until we can get further clarification
This is not about which version of Ceph per se is about which version of RHCS. My thinking is we do something similar to /etc/issue in that the version gets set (eg. 1.2.0) the first time you install the software as part of an explicit, core, common package (in Debian land I think this is base-files). In our case, it would probably be ceph-osd or ceph-mon. Individual packages can get updated via asyncs but when a major or point release install happens the version gets bumped (to 1.2.3).
Fixing the sha1 string in "ceph --version" is going to require a change to rdopkg, https://github.com/redhat-openstack/rdopkg/pull/30
Neil, do you still want to store this information in a file, here? If so, we can put it into the "ceph-base" package (this package contains files that all the MON/OSD/MDS daemons will share). /etc/redhat-ceph-storage ok?
Works for me.
Is it ok if the file is only on the MON, OSD, and MDS nodes? I propose we use the same format as /etc/os-release (https://www.freedesktop.org/software/systemd/man/os-release.html). So our file would contain: $ cat /etc/redhat-ceph-storage VERSION_ID="2.0" And we would bump that to 2.1, 2.2, etc for every minor point release.
+1
Not done in v10.0.4 yet.
Not done in v10.2.0 yet.