Bug #5493
closed
Zypper technique says skipping but returns UNKNOWN.
Description
I'm getting fancy unknowns returned from the zypper technique for otherwise good-looking runs - for example all repos are added:
host: # ls /etc/zypp/repos.d/
rudder-SLES11-SP2-Core.repo rudder-SLES11-SP2-LTSS-Updates.repo rudder-SLES11-SP2-Updates.repo
Not sure if an unknown state is always a bug... but this looks like one:
It says "Skipping" and "all already correct" but ends up with an unknown state nonetheless.
Screenshots
Test VMs:
Contact me privately for access to test repos, if needed.
Files
Updated by Florian Heigl about 10 years ago
- Description updated (diff)
@bundle agent check_zypper_settings {
vars:"zypper_name[1]" string => "SLES11-SP2-Core";
"zypper_name[2]" string => "SLES11-SP2-LTSS-Updates";
"/etc/zypp/repos.d/rudder-${zypper_name[${zypper_index}]}.repo"
create => "true",
perms => m("644"),
edit_line => set_zypper_repos("${zypper_name[${zypper_index}]}", "${zypper_url[${zypper_index}]}", "${zypper_enabled[${zypper_index}]}", "${zypper_type[${zypper_index}]}", "${g.rudder_too
ls}/zypper-repo.tpl"),
edit_defaults => empty_backup,
classes => kept_if_else("zypper_${zypper_index}_kept", "zypper_${zypper_index}_validated", "zypper_${zypper_index}_failed");SuSE.zypper_disablerepositories::"/etc/zypp/repos.d/.*"
"zypper_name[3]" string => "SLES11-SP2-Updates";"zypper_url[1]" string => "http://yayayayaayayadadada/repo/$RCE/SLES11-SP2-Core/sle-11-x86_64/";
"zypper_url[2]" string => "http://yayayayaayayadadada/repo/$RCE/SLES11-SP2-LTSS-Updates/sle-11-x86_64/";
"zypper_url[3]" string => "http://yayayayaayayadadada/repo/$RCE/SLES11-SP2-Updates/sle-11-x86_64/";"zypper_type[1]" string => "yast2";
"zypper_type[2]" string => "yast2";
"zypper_type[3]" string => "yast2";"zypper_enabled[1]" string => "1";
"zypper_enabled[2]" string => "1";
"zypper_enabled[3]" string => "1";"zypper_uuid[1]" string => "1fc56ad1-f302-4c92-8314-07ed7dfe447c@95108f15-c19e-4ce2-949a-9d268dd63ff2@6";
"zypper_uuid[2]" string => "1fc56ad1-f302-4c92-8314-07ed7dfe447c@95108f15-c19e-4ce2-949a-9d268dd63ff2@6";
"zypper_uuid3" string => "1fc56ad1-f302-4c92-8314-07ed7dfe447c@95108f15-c19e-4ce2-949a-9d268dd63ff2@6";- Repositories edition ?
"zypper_repositories_edit" expression => strcmp("true","true");
- Disable repositories ?
"zypper_disablerepositories" not => strcmp("false","false");
files:SuSE::
"/etc/zypp/zypp.conf"
create => "true",
perms => mog("644", "root", "root"),
edit_defaults => noempty_backup,
edit_line => set_advanced_zypper_config_values("check_zypper_settings.zmdconf", "${zypper_sections}"),
classes => kept_if_else("zypper_conf_kept", "zypper_conf_validated", "zypper_conf_failed");SuSE.zypper_repositories_edit::
:- perms => m("644"), # classes => kept_if_else("zypper_tier1_kept", "zypper_tier1_validated", "zypper_tier1_failed");
"/etc/zypp/repos.d/rudder-${zypper_name[${zypper_index}]}.repo"
create => "true",
perms => m("644"),
edit_line => set_zypper_repos("${zypper_name[${zypper_index}]}", "${zypper_url[${zypper_index}]}", "${zypper_enabled[${zypper_index}]}", "${zypper_type[${zypper_index}]}", "${g.rudder_too
ls}/zypper-repo.tpl"),
edit_defaults => empty_backup,
classes => kept_if_else("zypper_${zypper_index}_kept", "zypper_${zypper_index}_validated", "zypper_${zypper_index}_failed");SuSE.zypper_disablerepositories::"/etc/zypp/repos.d/.*"
delete => tidy,
file_select => ex_list("{zypper_files}"),
depth_search => recurse("inf"),
classes => kept_if_else("repos_disabled_kept", "repos_disabled_ok", "repos_disabled_fail"),
comment => "Delete the unwanted repos as requested";
Updated by Florian Heigl about 10 years ago
This is the .cf file as generated.
Updated by Nicolas CHARLES about 10 years ago
- Status changed from New to Discussion
- Assignee set to Florian Heigl
Hi Florian,
Thanks for the bug report. We'd need some more feedback on how you'd like to use this technique, to better fix it.
For instance, we have the disabled or edit repo, but there is no clear way on how they should be handled in case of multiple repos (and this is probably the cause for your issue)
thanks
Updated by Florian Heigl about 10 years ago
I'll verify this by removing all but one repos.
Assuming it is more complex to get it in perfect shape, and a bug fix is more helpful at the start. I suppose I could remove the critical part?
Florian
Updated by Nicolas CHARLES about 10 years ago
If you want, but we can also make it really usable with your real user feedback
Updated by Florian Heigl about 10 years ago
I tested, changing the number to only one repo did not help.
Feedback:
I think the separation of settings and repos in this technique is a good idea. Primary issue is just that it blows up if the system is as desired state.
The way I tried to set it up in Lab:
Two instances of the policy (it seems this triggers another bug, the one with "truetrue" for zypper_edit_repositories)
- 3 OS repositories (OS, Updates, Long Term Stable Updates)
- 3 SDK repositories
Specialized repos would be attached via further instances (i.e. one that has java jdk and veritas software for a veritas cluster node)
Further the field "add source repository" (is misnamed and) feels useless.
Hope this helps!
Beyond that I have crazy requirements that are of questionable use for others.... (repos should not be enabled except when installing, or funnier, the repo files should not be around unless needed)
Updated by Florian Heigl about 10 years ago
One more detail it is possible to set priorities right now, but they are not on repo level. I'm not sure this makes sense.
Another thing is the "rudder-" - Prefix on the repo files which I'd rather have as something optional. (but I can just modify that locally)
Updated by Florian Heigl about 10 years ago
Part about priorities -> nevermind, figured it's rudder priority, not like a yum repo priority ;)
Updated by Matthieu CERDA about 10 years ago
- Category set to Techniques
- Status changed from Discussion to Pending technical review
- Assignee changed from Florian Heigl to Jonathan CLARKE
- Priority changed from N/A to 3
- Target version set to 2.6.19
- % Done changed from 0 to 100
- Pull Request set to https://github.com/Normation/rudder-techniques/pull/539
Updated by Matthieu CERDA about 10 years ago
- Status changed from Pending technical review to Pending release
Applied in changeset policy-templates:commit:963c20598dbdf42c7724881266971e9b47e26824.
Updated by Jonathan CLARKE about 10 years ago
Applied in changeset policy-templates:commit:b6954bf8b704c43991a61a944609e5a69e4156e2.
Updated by Vincent MEMBRÉ about 10 years ago
- Status changed from Pending release to Released