On Thu, 8 Sep 2016, Wido den Hollander wrote:
> > Op 8 september 2016 om 15:24 schreef Sage Weil <sweil@xxxxxxxxxx>:
> > On Thu, 8 Sep 2016, Wido den Hollander wrote:
> > > > Op 8 september 2016 om 3:08 schreef Gregory Farnum <gfarnum@xxxxxxxxxx>:
> > > >
> > > >
> > > > On Tue, Sep 6, 2016 at 4:16 PM, Josh Durgin <jdurgin@xxxxxxxxxx> wrote:
> > > > > On 09/06/2016 12:18 PM, Wido den Hollander wrote:
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> wido@wido-laptop:~$ python -c "import rados; r = rados.Rados();
> > > > >> print(r.version())"
> > > > >> 0.69.1
> > > > >> wido@wido-laptop:~$ dpkg -l|grep rados|awk '{print $2" "$3}'
> > > > >> librados-dev 10.2.2-1trusty
> > > > >> librados2 10.2.2-1trusty
> > > > >> libradosstriper1 10.2.2-1trusty
> > > > >> python-rados 10.2.2-1trusty
> > > > >> wido@wido-laptop:~$
> > > > >>
> > > > >> Looking at librados.h in master I see:
> > > > >>
> > > > >> #define LIBRADOS_VER_MAJOR 0
> > > > >> #define LIBRADOS_VER_MINOR 69
> > > > >> #define LIBRADOS_VER_EXTRA 1
> > > > >>
> > > > >> Is this something which has just been forgotten to update?
> > > > >
> > > > >
> > > > > Pretty much. Not much has relied on the librados/librbd version numbers
> > > > > of this style. Adding tests for particular functions can be more
> > > > > reliable than checking version numbers, since sometimes functions are
> > > > > backported.
> > > > >
> > > > >> Looking at the 'ceph' tool I see:
> > > > >>
> > > > >> CEPH_GIT_NICE_VER="10.2.2"
> > > > >>
> > > > >> This is updated during packaging/build it seems.
> > > > >>
> > > > >> Should we maybe do that for librados.h as well?
> > > > >
> > > > >
> > > > > I see no reason not to.
> > > >
> > > > We at one point were trying to only increment the librados library
> > > > version when stuff actually changed. Shockingly, that manual
> > > > maintenance mostly resulted in it not getting updated. ;)
> > > > But is it really that helpful to just provide another way of exposing
> > > > the package version, instead of doing something that actually
> > > > illustrates what functions are around? :/
> > >
> > > I was using some Python code to gather Ceph information (
> > > https://github.com/42on/ceph-collect ). One of the things I wanted to
> > > know is the installed Ceph version and I used the version() method.
> > >
> > > It kept giving back 0.69.1 so I started looking into that.
> > >
> > > I just try to avoid calling subprocesses when this isn't required.
> > >
> > > Since the version() method is unreliable in giving back the version,
> > > what to do with it?
> >
> > Let's remove those #defines from the header, and then do something like
> > include the auto-generated ceph_ver.h in the package, and update the
> > version functions to #include that and return an accurate string...
> >
>
> yeah, one thing though.
>
> #define CEPH_GIT_VER @CEPH_GIT_VER@
> #define CEPH_GIT_NICE_VER "@CEPH_GIT_NICE_VER@"
>
> librados.h:
>
> CEPH_RADOS_API void rados_version(int *major, int *minor, int *extra);
>
> We don't have major, minor and extra stored separately in ceph_ver.h at the moment.
Let's just replace it with
CEPH_RADOS_API const char *rados_version_string();
CEPH_RADOS_API const char *rados_git_version_string();
We could parse the components out of the string, but I'm not sure it's
worth the effort?
sage
--
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
