On Thu, Sep 03, 2015 at 04:12:05PM +0200, Jiri Prochazka wrote:
2015-09-02 13:40 GMT+02:00 Ondrej Lichtner
<olichtne(a)redhat.com>:
> On Mon, Aug 31, 2015 at 12:08:56PM +0200, Jiri Prochazka wrote:
> > Hello,
> > I'd like to ask you about your opinion of the issue #136 [1].
> >
> > The first idea me and Jan had was this:
> > - Compute MD5 hash of files lnst-ctl, lnst-slave and all .py files in
> LNST
> > modules directory
> > - Compare it via hello message between Slave and Controller
> > - If hashes mismatch, end with an error
> >
> > However, there is a problem with path of the binary and module files.
> > When we are running LNST from git, lnst-ctl, lnst-slave and modules are
> all
> > in the same directory.
> > When we are running LNST from RPM or installation from git, binaries are
> in
> > /usr/bin/ or /bin/ and modules are in /usr/share/lnst/.
> >
> > I've came up with following approach to this, described in [2]. This way,
> > mixing of git and RPM is allowed, as long as all the important files are
> > the same.
> >
> > When the hashes are calculated, they are compared within the hello()
> method
> > on Controller.
> >
> > If you have any better solution or comments to this, both are very
> welcome
>
> I think dynamically calculated hashes are a completely wrong idea...
> when using rpms you often won't be installing both the Controller and
> the Slave on all the machines... so hashes calculated on hello() won't
> work.
>
> I say, let's do this the good old fashioned way -> save the major
> version number of LNST in a variable in both lnst-ctl and lnst-slave as
> global constants manually and just use that. When we update LNST to a
> newer version we also update this and that's that, no need to over
> complicate this.
>
> -Ondrej
>
> This does not completely help our case. We want to have
a check that Controller and Slave are compatible even
across major version. One of the solutions would
be minor versioning, when the version would be changed
after every patch that "breaks" the Controller-Slave
interface. The versioning could be also used for
our offically supported test_modules, etc.
Yeah, like I've proposed in person, minor versions could also solve the
problem with using git versions on different systems. I think we can go
with this solution to "just improve user friendliness", but I still
think that when using packaged LNST, major versions are enough and when
using LNST from git the user is expected to know what he's doing (since
the git is always considered as an "unstable" development version) and
should be able to figure out that he's doing wrong.
Anyway, the major version should be identical with the package version
that we have at the moment (8 right now). And the minor version will
start at 0 on each package update and will get bumped every time we
change the interface compatibility.
My suggestion is to place the version number somewhere in the Common
package, as a globally accessible constant (similar to lnst_config)
since that way it'll be accessible to both the Controller and Slave.
TL;DR you have my go ahead for implementing the major.minor version
checking between Controlled and Slave.
-Ondrej