Bug 2053829
| Summary: | [RFE] Kafo installer to ignore disabled modules | ||
|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Pavel Moravec <pmoravec> |
| Component: | Installation | Assignee: | satellite6-bugs <satellite6-bugs> |
| Status: | CLOSED WONTFIX | QA Contact: | Satellite QE Team <sat-qe-bz-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.10.0 | CC: | ehelms, gtalreja, saydas |
| Target Milestone: | Unspecified | Keywords: | FutureFeature, Triaged |
| Target Release: | Unused | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-09-28 13:15:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Can you expand further on what the actual bug is? Right now I am seeing a few issues that are masking what, if any, actual bug is present. 1) Users are editing satellite-answers.yaml directly -- they should not do this. We have attempted to expressly remove any mention of editing this from the documentation towards this end goal of ensuring users use the command line arguments. 2) Users are attempting to disable plugins directly, and while the installer does present --no-enable-* flags (we are aware of this and trying to address it) we, to my knowledge, do not support disabling anything generally speaking and only support a few specific cases as called out in the documentation. As I wrote, I noticed manual changes in the yaml files. Probably some "leftovers" from past changes that worked well in say 6.5, but started to raise issues in say 6.9. But I also know about some customers manually editing the files or managing symlinks of last-scenario or similar. I dont see anywhere in documentation any notice (or rather warning?) a user should not edit the config files. Neither a notice "use just explicitly mentioned options from satellite-installer". Hence both is officially allowed. We can change documentation to disallow both 1) and 2) and it will slowly change the customers' mind in such changes, if that is a viable / desired option of a resolution. My struggle with this request and issue is that it involves modifying the answer file directly which is a not supported, anti-pattern. Even though the scenario(s0 are unsupported, they happen. So even then, Kafo should be more robust - by either properly ignoring features disabled in answers file, or at least providing some more meaningfull error message, like Sayan wrote. Since understanding the cause of such an installer error is due to (unsupported, but happening) answers file edit, that is quite / redundantly challenging today. We are intending a few fixes around this area that should reduce, but not prevent this from happening. We cannot stop a user from editing this file directly regardless of what we do but we can try to help make it clearer they should not. As for the error handling, that is something we may look into but right now, given our priorities, we are opting not to address this directly. There will be changes coming in future versions that do aim to address this general concept. |
Description of problem: Please trivially enhance the module loading logic in kafo. We have hit the below situation many times: some customer disabled some puppet installer module (i.e. docker) by setting: foreman_proxy::plugin::docker: false to satellite-answers.yaml, but later on, installer fails with "No Puppet module parser is installed" error. We noticed it for various plugins both on Sat and Caps and it usually takes some time to identify the source of the problem. What is sufficient to change: /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/configuration.rb:133 : def modules @modules ||= begin register_data_types @data.keys.map { |mod| PuppetModule.new(mod, configuration: self).parse }.sort end end Here, the map is created even for modules having enabled: false, so they are mapped and attempted to parse. But some logix else-where does not load a parser for that module, due to the enabled: false. I *think* it should be enough to filter the map but I failed to write proper ruby code for it. Version-Release number of selected component (if applicable): Any Sat or Caps version How reproducible: 100% Steps to Reproduce: 1. "disable" an artificial plugin: echo "foreman_proxy::plugin::blah: false" >> /etc/foreman-installer/scenarios.d/satellite-answers.yaml 2. Run installer: satellite-installer Actual results: 2. fails with: Traceback (most recent call last): 19: from /usr/sbin/satellite-installer:8:in `<main>' 18: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/kafo_configure.rb:50:in `run' 17: from /opt/theforeman/tfm/root/usr/share/gems/gems/clamp-1.1.2/lib/clamp/command.rb:132:in `run' 16: from /opt/theforeman/tfm/root/usr/share/gems/gems/clamp-1.1.2/lib/clamp/command.rb:132:in `new' 15: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/kafo_configure.rb:140:in `initialize' 14: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/hooking.rb:65:in `execute' 13: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/hooking.rb:65:in `each' 12: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/hooking.rb:67:in `block in execute' 11: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/hook_context.rb:19:in `execute' 10: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/hook_context.rb:19:in `instance_eval' 9: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/hooking.rb:36:in `block (4 levels) in load' 8: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/hooking.rb:36:in `instance_eval' 7: from /usr/share/foreman-installer/hooks/boot/20-certs_update.rb:2:in `block (4 levels) in load' 6: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/hook_context.rb:113:in `module_present?' 5: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/kafo_configure.rb:257:in `module' 4: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/kafo_configure.rb:253:in `modules' 3: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/configuration.rb:133:in `modules' 2: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/configuration.rb:133:in `map' 1: from /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/configuration.rb:133:in `block in modules' /opt/theforeman/tfm/root/usr/share/gems/gems/kafo-6.4.0/lib/kafo/puppet_module.rb:70:in `parse': No Puppet module parser is installed and no cache of the file /usr/share/foreman-installer/modules/foreman_proxy/manifests/plugin/blah.pp is available. Please check debug logs and install optional dependencies for the parser. (Kafo::ParserError) Expected results: No such backtrace, blah module is ignored. Additional info: The error appears even if there is a blah.pp file with a proper content.