fix(helm): add pyyaml install task for fedora coreos

[LiquidPL]

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change

/kind bug

/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it:

As per ansible/ansible#69064 (comment) and https://docs.ansible.com/ansible/latest/collections/community/general/atomic_container_module.html, the package Ansible module on Fedora CoreOS uses the atomic_package module which is deprecated and doesn't handle rpm-ostree well. This PR adds a separate task for installing PyYAML in the kubernetes-apps/helm role specific to FCOS.
Which issue(s) this PR fixes:

Fixes #10885

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[linux-foundation-easycla]

• ✅login: LiquidPL / (f01fb11)

The committers listed above are authorized under a signed CLA.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: LiquidPL
Once this PR has been reviewed and has the lgtm label, please assign vannten for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @LiquidPL!

It looks like this is your first PR to kubernetes-sigs/kubespray 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kubespray has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @LiquidPL. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[tico88612]

/ok-to-test

[tico88612]

Can't CoreOS use package? EDIT: nevermind let me read description

[yankay]

have a question.

From #10165, pyyaml was introduced during the Helm installation process. However, pyyaml is not a required dependency of Helm. Recently, there have been multiple PRs addressing this dependency that seem to have caused some complications, such as:

• helm: fix pyyaml package on RH distros #10204
• Install PyYAML when helm is enabled #10213
• Fedora CoreOS fails to install PyYAML #10885
• Fix PyYAML package name on SLES and openSUSE #10794

Therefore, would it be more reasonable to remove pyyaml from the Helm installation process?

Do you mind share your thoughts, @tico88612 @VannTen. :-)

[tico88612]

@yankay PyYAML is not dependency of Helm, but if we need to use kubernetes.core.helm, it's required.

https://docs.ansible.com/ansible/latest/collections/kubernetes/core/helm_module.html

[LiquidPL]

Can't CoreOS use package? EDIT: nevermind let me read description

Yeah, from my testing package doesn't seem to work. However, through some extra testing I realized that my PR also sometimes breaks due to the usage of package_facts:

fatal: [homelab-control-plane-test-hva]: FAILED! => {"changed": false, "msg": "Could not detect a supported package manager from the following list: ['rpm'], or the required Python library is not installed. Check warnings for details."}

I believe that CoreOS is specific and minimal enough that it just doesn't work with regular Ansible tooling.

[VannTen]

Therefore, would it be more reasonable to remove pyyaml from the Helm installation process?

Do you mind share your thoughts, @tico88612 @VannTen. :-)

My opinion is that long term, we should remove any templating on the managed hosts and use exclusively

- command: kubectl apply -f - --server-side=true
  stdin: "{{ expanded resources }}" -> where this could be helm templates, kustomize output -> templating on the ansible control node.

(as we can see in #12254 , helm is a can of worms)

[VannTen]

On the other for the short term, installing packages should probably go in system_packages even if the package modules is not usable, and use the same filtering logic as the rest.

[LiquidPL]

I could move this to the system_packages role, although from what I can see, it is completely broken on CoreOS. I would need to do some further testing, but whenever my system would need any extra packages, the role would fail.

The way I see it, FCOS would need custom handling anyway, either using the community.general.rpm_ostree_pkg module, like I did in this PR, or with plain rpm-ostree calls like it's done in bootstrap_os. Would it be acceptable if I added custom logic for that distro inside that role?

[VannTen]

What I mean by moving to `system_packages` was to reuse the `pkgs` variables, but consume it in a different task, which would mirror the one using `package` using `rpm_ostree_pkg` instead (or whatever is appropriate). Does that make sense ? I don't think this should be too complicated , since the package filtering logic already exists ; but I'm not super familiar with coreos and similar, so that could be a bad assumption.