* librados.h version numbers
@ 2016-09-06 19:18 Wido den Hollander
2016-09-06 23:16 ` Josh Durgin
0 siblings, 1 reply; 8+ messages in thread
From: Wido den Hollander @ 2016-09-06 19:18 UTC (permalink / raw)
To: ceph-devel
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?
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?
Is there any other way (other then executing 'ceph -v') to get the version of the local librados?
Wido
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: librados.h version numbers 2016-09-06 19:18 librados.h version numbers Wido den Hollander @ 2016-09-06 23:16 ` Josh Durgin 2016-09-08 1:08 ` Gregory Farnum 0 siblings, 1 reply; 8+ messages in thread From: Josh Durgin @ 2016-09-06 23:16 UTC (permalink / raw) To: Wido den Hollander, ceph-devel 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. > Is there any other way (other then executing 'ceph -v') to get the version of the local librados? There is 'librados-config --version' if you have the -dev package installed. Josh ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: librados.h version numbers 2016-09-06 23:16 ` Josh Durgin @ 2016-09-08 1:08 ` Gregory Farnum 2016-09-08 6:59 ` Wido den Hollander 0 siblings, 1 reply; 8+ messages in thread From: Gregory Farnum @ 2016-09-08 1:08 UTC (permalink / raw) To: Josh Durgin; +Cc: Wido den Hollander, ceph-devel On Tue, Sep 6, 2016 at 4:16 PM, Josh Durgin <jdurgin@redhat.com> 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? :/ -Greg ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: librados.h version numbers 2016-09-08 1:08 ` Gregory Farnum @ 2016-09-08 6:59 ` Wido den Hollander 2016-09-08 13:24 ` Sage Weil 0 siblings, 1 reply; 8+ messages in thread From: Wido den Hollander @ 2016-09-08 6:59 UTC (permalink / raw) To: Gregory Farnum, Josh Durgin; +Cc: ceph-devel > Op 8 september 2016 om 3:08 schreef Gregory Farnum <gfarnum@redhat.com>: > > > On Tue, Sep 6, 2016 at 4:16 PM, Josh Durgin <jdurgin@redhat.com> 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? Wido > -Greg > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: librados.h version numbers 2016-09-08 6:59 ` Wido den Hollander @ 2016-09-08 13:24 ` Sage Weil 2016-09-08 13:29 ` Wido den Hollander 0 siblings, 1 reply; 8+ messages in thread From: Sage Weil @ 2016-09-08 13:24 UTC (permalink / raw) To: Wido den Hollander; +Cc: Gregory Farnum, Josh Durgin, ceph-devel On Thu, 8 Sep 2016, Wido den Hollander wrote: > > Op 8 september 2016 om 3:08 schreef Gregory Farnum <gfarnum@redhat.com>: > > > > > > On Tue, Sep 6, 2016 at 4:16 PM, Josh Durgin <jdurgin@redhat.com> 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... sage ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: librados.h version numbers 2016-09-08 13:24 ` Sage Weil @ 2016-09-08 13:29 ` Wido den Hollander 2016-09-08 13:38 ` Sage Weil 0 siblings, 1 reply; 8+ messages in thread From: Wido den Hollander @ 2016-09-08 13:29 UTC (permalink / raw) To: Sage Weil; +Cc: Gregory Farnum, Josh Durgin, ceph-devel > Op 8 september 2016 om 15:24 schreef Sage Weil <sweil@redhat.com>: > > > On Thu, 8 Sep 2016, Wido den Hollander wrote: > > > Op 8 september 2016 om 3:08 schreef Gregory Farnum <gfarnum@redhat.com>: > > > > > > > > > On Tue, Sep 6, 2016 at 4:16 PM, Josh Durgin <jdurgin@redhat.com> 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. Wido > sage > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: librados.h version numbers 2016-09-08 13:29 ` Wido den Hollander @ 2016-09-08 13:38 ` Sage Weil 2016-09-09 6:51 ` Wido den Hollander 0 siblings, 1 reply; 8+ messages in thread From: Sage Weil @ 2016-09-08 13:38 UTC (permalink / raw) To: Wido den Hollander; +Cc: Gregory Farnum, Josh Durgin, ceph-devel On Thu, 8 Sep 2016, Wido den Hollander wrote: > > Op 8 september 2016 om 15:24 schreef Sage Weil <sweil@redhat.com>: > > On Thu, 8 Sep 2016, Wido den Hollander wrote: > > > > Op 8 september 2016 om 3:08 schreef Gregory Farnum <gfarnum@redhat.com>: > > > > > > > > > > > > On Tue, Sep 6, 2016 at 4:16 PM, Josh Durgin <jdurgin@redhat.com> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: librados.h version numbers 2016-09-08 13:38 ` Sage Weil @ 2016-09-09 6:51 ` Wido den Hollander 0 siblings, 0 replies; 8+ messages in thread From: Wido den Hollander @ 2016-09-09 6:51 UTC (permalink / raw) To: Sage Weil; +Cc: Gregory Farnum, Josh Durgin, ceph-devel > Op 8 september 2016 om 15:38 schreef Sage Weil <sweil@redhat.com>: > > > On Thu, 8 Sep 2016, Wido den Hollander wrote: > > > Op 8 september 2016 om 15:24 schreef Sage Weil <sweil@redhat.com>: > > > On Thu, 8 Sep 2016, Wido den Hollander wrote: > > > > > Op 8 september 2016 om 3:08 schreef Gregory Farnum <gfarnum@redhat.com>: > > > > > > > > > > > > > > > On Tue, Sep 6, 2016 at 4:16 PM, Josh Durgin <jdurgin@redhat.com> 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? > No, I don't think so. Seems good to me to add these functions and remove the old version() method. Wido > sage ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-09-09 6:51 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-06 19:18 librados.h version numbers Wido den Hollander 2016-09-06 23:16 ` Josh Durgin 2016-09-08 1:08 ` Gregory Farnum 2016-09-08 6:59 ` Wido den Hollander 2016-09-08 13:24 ` Sage Weil 2016-09-08 13:29 ` Wido den Hollander 2016-09-08 13:38 ` Sage Weil 2016-09-09 6:51 ` Wido den Hollander
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.