Project

General

Profile

Actions

Bug #5493

closed

Zypper technique says skipping but returns UNKNOWN.

Added by Florian Heigl over 9 years ago. Updated over 9 years ago.

Status:
Released
Priority:
3
Category:
Techniques
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

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

Rudder_zypper_unknown.png (74.3 KB) Rudder_zypper_unknown.png Florian Heigl, 2014-09-05 16:06
rudder_zypper_unknown_2.png (96.8 KB) rudder_zypper_unknown_2.png Florian Heigl, 2014-09-05 16:06
zypperPackageManagementSettings.cf (12.4 KB) zypperPackageManagementSettings.cf Florian Heigl, 2014-09-05 16:13

Related issues 1 (0 open1 closed)

Related to Rudder - Bug #5662: Zypper Management Technique doesn't behave correctly, and should be splitted in two separated techniquesReleasedJonathan CLARKE2014-11-12Actions
Actions #1

Updated by Florian Heigl over 9 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";
  1. Repositories edition ?
    "zypper_repositories_edit" expression => strcmp("true","true");
  1. 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::
:
  1. 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";
Actions #2

Updated by Florian Heigl over 9 years ago

This is the .cf file as generated.

Actions #3

Updated by Nicolas CHARLES over 9 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

Actions #4

Updated by Florian Heigl over 9 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

Actions #5

Updated by Nicolas CHARLES over 9 years ago

If you want, but we can also make it really usable with your real user feedback

Actions #6

Updated by Florian Heigl over 9 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)

  1. 3 OS repositories (OS, Updates, Long Term Stable Updates)
  2. 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)

Actions #7

Updated by Florian Heigl over 9 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)

Actions #8

Updated by Florian Heigl over 9 years ago

Part about priorities -> nevermind, figured it's rudder priority, not like a yum repo priority ;)

Actions #9

Updated by Matthieu CERDA over 9 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
Actions #10

Updated by Matthieu CERDA over 9 years ago

  • Status changed from Pending technical review to Pending release

Applied in changeset policy-templates:commit:963c20598dbdf42c7724881266971e9b47e26824.

Actions #11

Updated by Jonathan CLARKE over 9 years ago

Applied in changeset policy-templates:commit:b6954bf8b704c43991a61a944609e5a69e4156e2.

Actions #12

Updated by Vincent MEMBRÉ over 9 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 2.6.19, 2.10.7 and 2.11.4, which were these days.

Actions

Also available in: Atom PDF