15.8.0-rc3

[jrha]

Top level issue tracker for any blocking issues discovered with 15.8.0-rc3.

[jrha]

First test of upgrade on a sl6x VM at RAL seems superficially fine.

[jouvin]

Attempt to use create-vanilla-SCDB.sh and to compile the examples produces the error:

     [panc] validation error [/tmp/scdb-vanilla/cfg/clusters/umd3/profiles/se-dpm-disk2.example.org.pan]
     [panc] user-defined validation failed
     [panc] element path: '/software/components/grub/version'
     [panc] element value: 14.8.0-rc4-SNAPSHOT
     [panc] type: 'structure_component' [/tmp/scdb-vanilla/cfg/quattor/14.8.0-rc3/quattor/schema.pan:470.28-477.1]
     [panc] type: 'component_grub_type' [/tmp/scdb-vanilla/cfg/quattor/14.8.0-rc3/components/grub/schema.pan:32.28-37.1]
     [panc] path '/software/components/grub' bound to type component_grub_type in [/tmp/scdb-vanilla/cfg/quattor/14.8.0-rc3/components/grub/schema.pan:40.36-40.54]

I'm looking at the error, probably trivial... But this underlines once again that we'll save a lot of effort if we were able to compile examples as part of templates and possibly configuration modules development...

[jouvin]

In fact this looks as something more serious than I thought.... there was no change in the grub config module. Was there any mod to the Maven plugin doing the replacement for things like ${no-snapshot-version}?

BTW, I find suspect that the value is 14.8.0-rc4-SNAPSHOT rather than 14.8.0-rc3...

[jrha]

Line 30 in the tagged template library looks correct to me, did create-vanilla-SCDB.sh do the right thing?

I used ./get-template-library 15.8.0-rc3 to update an aquilon sandbox and didn't see this problem.

[jrha]

Cannot replicate.

I just ran utils/scdb/create-vanilla-SCDB.sh -F -d /tmp/scdb 15.8.0-rc3 on a fresh VM and got

compile.cluster.profiles:
     [echo] Cluster: umd3 in /tmp/scdb/cfg/clusters/grid
     [panc] 13/13 object template(s) being processed
     [panc] 13 templates
     [panc] 13/13 compiled, 0/0 annotations, 26/26 xml, 0/0 dependency
     [panc] 0 errors, 4,344 ms, 175 MB/926 MB heap, 15 MB/214 MB nonheap
     [panc] 

all:

BUILD SUCCESSFUL
Total time: 28 seconds

What did you do?

[jrha]

I should note that cfg/clusters/opennebula and cfg/clusters/openstack do not build, but I don't think that is a new issue.

[jouvin]

Sorry for the mistake. I typed 14.8.0-rc3 instead of 15.8.0-rc3... I'll try to deploy it on real machinestomorrow.

[stdweird]

i have a minor complaint: the new structure_rack type has 3 new mandatory fields, which would force us to modify a lot of our hardware templates (i'm going to run with these fields as optional fields to continue testing).

[jouvin]

I found a minor issue in ncm-network, see quattor/configuration-modules-core#589. Probably an old problem as there was no recent change in this config module. Certainly not a reason to delay the release.

[jouvin]

About @stdweird's comment, any good reason for not defining these properties as optional?

[guillaume-philippon]

15.8.0-rc3 overwrite /etc/ccm.conf to the default file which broke ccm-fetch and ncm-ccm (which need a valid /etc/ccm.conf)

[jouvin]

It would have been good to fix the CCM pb before closing this ticket. This is clearly a showstopper...

[jrha]

This should not have been closed by quattor/configuration-modules-core#594, bad @stdweird.

[jrha]

PRs should not reference tracker tickets, new issues should be created in the appropriate repositories which are referenced by the tracker.

[stdweird]

@jrha new blocker: quattor/configuration-modules-core#594 and quattor/CAF#112 cause ncm-ccm to fail: ccm-fetch is given a pipe which is supposed to be read twice: once by CAF::Application, once by CCM::CCfg. looking for a solution...

[jrha]

Next RC coming soon.