15.8.0-rc5

[jrha]

Top level issue tracker for any blocking issues discovered with 15.8.0-rc5.
Replaces #109.

[jouvin]

I successfully deployed this RC on the test grid machines at LAL.

[jrha]

Everything looks fine on an SL7 VM at RAL.

[stdweird]

@guillaume-philippon can you try to break things again? you were very succesful last time 😃

[jouvin]

In fact, I was the person who broke the things, Guillaume is the person who fixed it, with you!

[jouvin]

And to be explcit: my first comment was to say that I didn't succeed to break it again!

[jouvin]

Trying to deploy more nodes, I found a schema issue with /system/network/nisdomain:

     [panc] element path: '/system/network/nisdomain'
     [panc] element value: lal-orsay
     [panc] type: 'type_fqdn' [/scratch/jouvin/quattor/cdb/cfg/quattor/15.8.0-rc5/pan/types.pan:440.18-440.28]
     [panc] type: 'structure_network' [/scratch/jouvin/quattor/cdb/cfg/quattor/15.8.0-rc5/components/network/core-schema.pan:208.26-224.1]
     [panc] type: 'structure_system' [/scratch/jouvin/quattor/cdb/cfg/quattor/15.8.0-rc5/quattor/types/system.pan:39.25-61.1]
     [panc] type: 'structure_profile' [/scratch/jouvin/quattor/cdb/cfg/quattor/15.8.0-rc5/quattor/schema.pan:27.26-32.1]
     [panc] path '/' bound to type structure_profile in [/scratch/jouvin/quattor/cdb/cfg/quattor/15.8.0-rc5/quattor/profile_base.pan:7.12-7.28]

I don't really understand where this is coming from. I see no related change in either ncm-network (core-schema.pan) or in pan/types.pan (type_fqdn definition). Anybody with an idea? I don't really understand either the type_fqdn requirement as lal-orsay is not precisely a FQDN. But this has always been our NIS domain name and it worked so far...

[jrha]

Seems simple enough to me, nisdomain should not be type_fqdn.

[jouvin]

For me too... But doing a git blame, the change was introduced by @iancollier in 2013... and it worked since then for us. So before changing this, I'd like to understand what trigged the error in the RC. And I have no clue so far!

[jrha]

We fixed the logic in is_fqdn during this release, it had a bug that was matching short hostnames.

[jrha]

See quattor/template-library-core@a24dcd4, which was part of quattor/template-library-core#76

[jouvin]

I had this in mind but was not able to spot it during my quick search... So clearly with a fixed is_fqdn, we need to fix the schema! Should be a string I think.

[jrha]

Hmm, that seems too loose, I'll see if I can find any documentation on what it is allowed to be.

[jrha]

No helpful documentation yet, but some source code I found has:

static char domain[1025];

It clearly also cannot contain spaces, because that would break the parsing of yp.conf
At least one man page states it is case-sensitive.

Experiments seem to indicate that anything short of white-space is accepted, so at least...

nisdomain ? string(1..1024) with match(SELF, '^\S+$')

[jrha]

Then again I have also just found:

count = sscanf (cp, "domain %64s server %80s", tmpdomain, tmpserver);

Testing ypbind with more than 64 characters in yp.conf gives an entry is not valid error.

So let's make that:

nisdomain ? string(1..64) with match(SELF, '^\S+$')

[jrha]

Next RC on the way...

[jrha]

I'm getting stuck (on at least SL6) on a failure of a single test on ncm-autofs, it's not reproducible outside of build_all_repos (i.e. with mvn test) but happens every time I run the full script.

not ok 90 - service autofs status not checked (no changes in 2nd run)
1..90
[VERB] Not saving file /etc/autofs.conf
[VERB] Changes to /etc/autofs.conf:
updated /root/quattordev/repos/configuration-modules-core/ncm-autofs/target/test/cache/maps/profile.2/profile.url
updated /root/quattordev/repos/configuration-modules-core/ncm-autofs/target/test/cache/maps/profile.2/profile.xml
[VERB] File /root/quattordev/repos/configuration-modules-core/ncm-autofs/target/test/cache/maps/profile.2/profile.xml was modified
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/90 subtests
src/test/perl/pod-syntax.t ..
1..2

[jrha]

Actually I can reproduce it with mvn clean test -Dprove.args=-v

[stdweird]

@jrha build all repos runs fine for me on el5,6,7 (yesterday).

i need more output to debug this. either run the mvn command with QUATTOR_TEST_LOG_CMD_MISSING=1 QUATTOR_TEST_LOG_CMD=1 QUATTOR_TEST_LOG_DEBUGLEVEL=3 exported (or use the wrapper funcitons from quattor/quattor.github.com#146 (comment)), or use run build_all_repos with export DEBUG=1

i actually need the output above the errors, but feel free to send me the whole output

[jrha]

Full log here: https://gist.github.com/jrha/1b93d7d7d7f72b833ae4

[jrha]

It is odd, because this has been running fine on (supposedly) identical VMs.

[stdweird]

the gist was executed as root? all my tests run as quattor user via https://github.com/quattor/release/blob/master/src/scripts/context_init_build_all_repos.sh
i'll have a look in a bit

[stdweird]

@jrha if /etc/autofs.conf is present, the tests fails. if not, all is fine. has nothing to do with running as root or not. this must be a bug in Test::Quattor.

[stdweird]

i would suggest testing without the file present

[jrha]

RC6 built happily with this workaround!