Rudder

here :)

<TECHNIQUE name="Zypper_Repo_SLES11_SP1">
<DESCRIPTION>Repository settings for SLES11 SP1</DESCRIPTION>
<BUNDLES>
<NAME>Zypper_Repo_SLES11_SP1</NAME>
<NAME>Zypper_Repo_SLES11_SP1_rudder_reporting</NAME>
</BUNDLES>
<TMLS>
<TML name="rudder_reporting"/>
</TMLS>
<SECTIONS>
<SECTION component="true" multivalued="true" name="File create">
<REPORTKEYS>
<VALUE>/etc/zypp/repos.d/SLES11sp1-spir.repo</VALUE>
</REPORTKEYS>
</SECTION>
<SECTION component="true" multivalued="true" name="OS SuSE Version ">
<REPORTKEYS>
<VALUE>11</VALUE>
</REPORTKEYS>
</SECTION>
<SECTION component="true" multivalued="true" name="File enforce content">
<REPORTKEYS>
<VALUE>/etc/zypp/repos.d/SLES11sp1-spir.repo</VALUE>
</REPORTKEYS>
</SECTION>
<SECTION component="true" multivalued="true" name="Os suse patchlevel">
<REPORTKEYS>
<VALUE>1</VALUE>
</REPORTKEYS>
</SECTION>
</SECTIONS>
</TECHNIQUE>

So, the metadata is requiring "rudder_reporting.st" with the line: "<TML name="rudder_reporting"/>".

Now, we need to know why it is so and:

1/ if it was actually NOT required, why the rudderify script generated a bad metadata.xml,
2/ if it WAS required, why the rudderify script didn't generated the correct "rudder_reporting.st" file.

Could you give us the ncf technique (should be located in /var/rudder/configuration-repository/ncf/50_techniques/NAME_OF_TECHNIQUE/xxx.cf ? Thanks

i deleted the technique yesterday. i make another test this morning...

I have created another technique based on 2 generics.

here is the technique :

1. @name TEST_ENSURE_SLES_FILE
2. @description TEST_ENSURE_SLES_FILE
3. @version 1.0

bundle agent TEST_ENSURE_SLES_FILE {
methods:
"method_call" usebundle => Os_SuSE_Version("11"),
ifvarclass => "any";
"method_call" usebundle => Os_SuSE_patchlevel("1"),
ifvarclass => "Os_SuSE_Version_11_kept";
"method_call" usebundle => file_create("/root/TEST_ENSURE_SLES_FILE"),
ifvarclass => "Os_SuSE_patchlevel_1_kept";
"method_call" usebundle => file_ensure_lines_present("/root/TEST_ENSURE_SLES_FILE", "This is a SLES 11 Service Pack 1"),
ifvarclass => "file_create__root_TEST_ENSURE_SLES_FILE_repaired";
}

In this case, i have no metadata or st file.

Jean Marie,

I have trouble reproducing this issue, I created a very similar technique to yours, with the technique builder.
It lies in /var/rudder/configuration-repository/ncf/30_generic_methods/TEST_ENSURE_SLES_FILE/TEST_ENSURE_SLES_FILE.cf
I added the technique in the active technique librairy, and I do have metadata.xml and rudder_reporting.st files in /var/rudder/configuration-repository/techniques/ncf_techniques/TEST_ENSURE_SLES_FILE/1.0

My guess is that there may be an issue with the generic methods you created; is there a way for you to send them to us ?

Ok, we have two error in one:
- the script that generates the technique doesn't properly looks for the user generted generic method
- the git post commit that generates the technique doesn't catch the error, and silently fails

Any idea to fix that ?

Hi Jean-Marie,

The underlying issue was fixed in http://www.rudder-project.org/redmine/issues/5865
To fix your issue, you can copy the file https://raw.githubusercontent.com/Normation/ncf/master/tools/ncf_rudder.py to /usr/share/ncf/tools/ncf_rudder.py on your server, restart httpd service, and update your technique.
It should fix everything

I'm linking this issue with #5685, as the part "it doesn't raise an error" needs to be addressed