ctdb tests

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

ctdb tests

Andreas Schneider-15
Hi Amitay and Martin,

I've just packaged Samba 4.6rc3 and the list of added ctdb tests is huge.
Attached is the diff of the spec file. I just want to make sure.

You want all these tests installed in the system, and you can run them
installed there?


Thanks,


        Andreas


--
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             [hidden email]
www.samba.org

samba.spec.diff (33K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ctdb tests

Martin Schwenke
Hi Andreas,

On Tue, 14 Feb 2017 18:31:10 +0100, Andreas Schneider <[hidden email]>
wrote:

> I've just packaged Samba 4.6rc3 and the list of added ctdb tests is huge.
> Attached is the diff of the spec file. I just want to make sure.
>
> You want all these tests installed in the system, and you can run them
> installed there?

The CTDB tests were not being installed by a top level Samba install:

  https://bugzilla.samba.org/show_bug.cgi?id=12547

They were being installed as part of a standalone CTDB install, which
is why we didn't notice.

Yes, being able to install all of this is very useful.

Each night we build RPMs for a list of branches.  Then we use
autocluster to create a cluster.  We install ctdb on the cluster nodes
and ctdb-tests on a test node.  Then we are able to run ctdb_run_tests
to run most of the tests on the test node and ctdb_run_cluster_tests to
run some of the tests against the real cluster.

Having the tests installed matters most for the cluster tests.  There's
some directory name consistency mangling needed to ensure that the test
code can find things on the cluster nodes.  The cluster tests aren't
currently run as part of autobuild... because they need a cluster and
we've never quite got there...  :-)

peace & happiness,
martin

Reply | Threaded
Open this post in threaded view
|

Re: ctdb tests

Amitay Isaacs
On Wed, Feb 15, 2017 at 8:41 AM, Martin Schwenke <[hidden email]> wrote:

> Hi Andreas,
>
> On Tue, 14 Feb 2017 18:31:10 +0100, Andreas Schneider <[hidden email]>
> wrote:
>
> > I've just packaged Samba 4.6rc3 and the list of added ctdb tests is huge.
> > Attached is the diff of the spec file. I just want to make sure.
> >
> > You want all these tests installed in the system, and you can run them
> > installed there?
>
> The CTDB tests were not being installed by a top level Samba install:
>
>   https://bugzilla.samba.org/show_bug.cgi?id=12547
>
> They were being installed as part of a standalone CTDB install, which
> is why we didn't notice.
>
> Yes, being able to install all of this is very useful.
>
> Each night we build RPMs for a list of branches.  Then we use
> autocluster to create a cluster.  We install ctdb on the cluster nodes
> and ctdb-tests on a test node.  Then we are able to run ctdb_run_tests
> to run most of the tests on the test node and ctdb_run_cluster_tests to
> run some of the tests against the real cluster.
>
> Having the tests installed matters most for the cluster tests.  There's
> some directory name consistency mangling needed to ensure that the test
> code can find things on the cluster nodes.  The cluster tests aren't
> currently run as part of autobuild... because they need a cluster and
> we've never quite got there...  :-)
>
> peace & happiness,
> martin
>
>
As Martin mentioned, we have a need to be able to package ctdb tests for
daily tests.  For that we rely on building ctdb packages using
ctdb/packaging/RPM/ctdb.spec.in.

We have been adding quite a lot of tests in recent years since there have
been significant changes to the core infrastructure of CTDB.  And the tests
will continue to grow in numbers as long as we are doing new development.
I am not sure if it makes sense for distributions to package ctdb-tests (or
for that matter samba-tests), unless it's a policy to package everything
that gets installed.

We do not rely on distributions packaging ctdb-tests for any sort of
testing.  I would be fine even if distributions decide to drop ctdb-tests
package altogether.

Amitay.
Reply | Threaded
Open this post in threaded view
|

Re: ctdb tests

Andreas Schneider-15
In reply to this post by Martin Schwenke
On Tuesday, 14 February 2017 22:41:22 CET Martin Schwenke wrote:
> Hi Andreas,

Hi Martin,
 

> On Tue, 14 Feb 2017 18:31:10 +0100, Andreas Schneider <[hidden email]>
>
> wrote:
> > I've just packaged Samba 4.6rc3 and the list of added ctdb tests is huge.
> > Attached is the diff of the spec file. I just want to make sure.
> >
> > You want all these tests installed in the system, and you can run them
> > installed there?
>
> The CTDB tests were not being installed by a top level Samba install:
>
>   https://bugzilla.samba.org/show_bug.cgi?id=12547
>
> They were being installed as part of a standalone CTDB install, which
> is why we didn't notice.

thanks for the clarification.

Another issue:

New file /usr/share/ctdb/tests/simple/nodes is a dangling symlink (to /etc/
ctdb/nodes) on all architectures

/etc/ctdb/nodes doesn't exist, also not in the upstream ctdb.spec.in.


You might want to look into that.



        Andreas


--
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             [hidden email]
www.samba.org

Reply | Threaded
Open this post in threaded view
|

Re: ctdb tests

Martin Schwenke
On Wed, 15 Feb 2017 18:32:09 +0100, Andreas Schneider <[hidden email]>
wrote:

> On Tuesday, 14 February 2017 22:41:22 CET Martin Schwenke wrote:

> > On Tue, 14 Feb 2017 18:31:10 +0100, Andreas Schneider <[hidden email]>
> > wrote:  
> > > I've just packaged Samba 4.6rc3 and the list of added ctdb tests is huge.
> > > Attached is the diff of the spec file. I just want to make sure.
> > >
> > > You want all these tests installed in the system, and you can run them
> > > installed there?  
> >
> > The CTDB tests were not being installed by a top level Samba install:
> >
> >   https://bugzilla.samba.org/show_bug.cgi?id=12547
> >
> > They were being installed as part of a standalone CTDB install, which
> > is why we didn't notice.  
>
> thanks for the clarification.
>
> Another issue:
>
> New file /usr/share/ctdb/tests/simple/nodes is a dangling symlink (to /etc/
> ctdb/nodes) on all architectures
>
> /etc/ctdb/nodes doesn't exist, also not in the upstream ctdb.spec.in.
>
>
> You might want to look into that.

This is due to the directory path mangling I mentioned.  It doesn't
matter too much...

In the ctdb_run_cluster_tests case, where tests are run against a real
cluster, we expect /etc/ctdb/nodes on the test node to be configured
identically to the cluster nodes.  This lets the tests run on the test
node access the cluster nodes using the onnode command.

In the ctdb_run_tests case, where tests are run against local daemons
on the test node, the local daemons setup overrides the nodes file, so
this is not used.

This way of doing things allows the same tests to be run in-tree or
when installed.  It took a bit of fiddling to get this right...  ;-)

We could install an empty nodes file when we install CTDB.  The normal
convention when doing this would be to put some comments in the "empty"
file as a hint to the user.  However, comment lines are significant in
the CTDB nodes files, so I'm reluctant to do that.  Nobody important
uses the upstream ctdb.spec.in so I'm ambivalent about the dangling
symlink.

If you want to resolve a packaging dilemma then you could create an
empty nodes file (with or without comments) in the main ctdb package.

Alternatively, following Amitay's suggestion, you could decide not to
package ctdb-tests when packaging Samba for a distro.  Part of this
alternative might be to do surgery on ctdb/wscript so that test code
isn't built/installed if, say, --enable-selftest isn't set.  If
everything is sane, that should just mean putting:

      if not bld.env.standalone_ctdb:
        if not conf.CONFIG_GET('ENABLE_SELFTEST'):
            return

in ctdb/wscript:build() before the test stuff.

Standalone CTDB builds would always build the test stuff and no other
changes should be needed... and we can keep our nasty dangling
symlink... because that's the way we like it...  :-)

Thoughts?

peace & happiness,
martin