Bug #5828
closedMissing st file
Description
Hi
I built a new technique with NCF builder, containing my own generic method.
Policies can't be updated due to st file missing on
/rudder/configuration-repository/techniques/ncf_techniques/TECH_NAME/1.0/
The exact message is:
Policy update error for process '55' at 2014-11-26 11:21:22 ⇨ Cannot write configuration node ⇨ Error when
trying to open template 'TECH_NAME/1.0/rudder_reporting.st'. Check that the file exists and is
correctly commited in Git, or that the metadata for the technique are corrects.
If i "touch" an empty st file like 'rudder_reporting.st', its seems to be ok.
Files
Updated by François ARMAND about 10 years ago
- Description updated (diff)
- Category set to Web - Technique editor
- Target version set to 2.11.5
Hi,
Thanks!
Some more context:
The technique is built from a new generic method. The generic method was added in /var/rudder/configuration-repository/ncf/30_generic_methods and then appear in ncf-builder.
The technique correctly generates the csv file for reports and metadata.xml, but no 'rudder_reporting.st' (because, a priori, none id needed).
When a rule try to use the technique and promise are generated, the error message about the missing rudder_reporting.st appears.
Rudder version is 2.11.3.
Jean-Marie, if possible, could you attach or copy/paste the generated metadata.xml ?
Thanks
Updated by Jean Marie ARIES about 10 years ago
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>
Updated by François ARMAND about 10 years ago
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
Updated by Jean Marie ARIES about 10 years ago
i deleted the technique yesterday. i make another test this morning...
Updated by Jean Marie ARIES about 10 years ago
I have created another technique based on 2 generics.
here is the technique :
- @name TEST_ENSURE_SLES_FILE
- @description TEST_ENSURE_SLES_FILE
- @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.
Updated by Nicolas CHARLES about 10 years ago
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 ?
Updated by Jean Marie ARIES about 10 years ago
- File Os_suse_patchlevel.cf Os_suse_patchlevel.cf added
- File Os_suse_version.cf Os_suse_version.cf added
Hi Nicolas,
See attachments.
This is the two generics I used to make the test.
Updated by Nicolas CHARLES about 10 years ago
- Assignee set to Nicolas CHARLES
- Priority changed from N/A to 1 (highest)
Ok, I can reproduce the issue with your generic methods
Thank you
Updated by Nicolas CHARLES about 10 years ago
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
Updated by Nicolas CHARLES almost 10 years ago
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
Updated by Vincent MEMBRÉ almost 10 years ago
- Target version changed from 2.11.5 to 2.11.6
Updated by Nicolas CHARLES almost 10 years ago
I'm linking this issue with #5685, as the part "it doesn't raise an error" needs to be addressed
Updated by Vincent MEMBRÉ almost 10 years ago
- Target version changed from 2.11.6 to 2.11.7
Updated by Vincent MEMBRÉ almost 10 years ago
- Target version changed from 2.11.7 to 2.11.8
Updated by Vincent MEMBRÉ over 9 years ago
- Target version changed from 2.11.8 to 2.11.9
Updated by Vincent MEMBRÉ over 9 years ago
- Target version changed from 2.11.9 to 2.11.10
Updated by Vincent MEMBRÉ over 9 years ago
- Target version changed from 2.11.10 to 2.11.11
Updated by Vincent MEMBRÉ over 9 years ago
- Target version changed from 2.11.11 to 2.11.12
Updated by Vincent MEMBRÉ over 9 years ago
- Target version changed from 2.11.12 to 2.11.13
Updated by Vincent MEMBRÉ over 9 years ago
- Target version changed from 2.11.13 to 2.11.14
Updated by Vincent MEMBRÉ about 9 years ago
- Target version changed from 2.11.14 to 2.11.15
Updated by Vincent MEMBRÉ about 9 years ago
- Target version changed from 2.11.15 to 2.11.16
Updated by Vincent MEMBRÉ about 9 years ago
- Target version changed from 2.11.16 to 2.11.17
Updated by Vincent MEMBRÉ almost 9 years ago
- Target version changed from 2.11.17 to 2.11.18
Updated by Vincent MEMBRÉ almost 9 years ago
- Target version changed from 2.11.18 to 2.11.19
Updated by Vincent MEMBRÉ almost 9 years ago
- Target version changed from 2.11.19 to 2.11.20
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 2.11.20 to 2.11.21
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 2.11.21 to 2.11.22
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 2.11.22 to 2.11.23
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 2.11.23 to 2.11.24
Updated by Vincent MEMBRÉ over 8 years ago
- Target version changed from 2.11.24 to 308
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 308 to 3.1.14
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 3.1.14 to 3.1.15
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 3.1.15 to 3.1.16
Updated by Vincent MEMBRÉ about 8 years ago
- Target version changed from 3.1.16 to 3.1.17
Updated by Nicolas CHARLES about 8 years ago
- Status changed from New to Rejected
Rejecting issue as the underlying problem has been fixed