Align Helm/Ansible plugins with the changes made for Golang ( go/v3 )

[camilamacedo86]

Describe the problem you need a feature to resolve.

Currently, Helm/Ansible plugins have been scaffolding the files common files ( config, makefile ) which are not aligned with the latest changes for Golang go/v3.

A few bad side effect regarding Helm/Ansible starts to deviate from Golang are:

• The common docs start not to work for all and no longer be common.
• Starts to be harder to know what is expected and troubleshooting the issues raised to help the users
• Starts to be more challenging to keep the projects maintained and compatible with KB and SDK common features across the board.
• It starts to be hard for users and maintainers to use and collab with them since each type will have a specific behaviour and workflow and are no longer homogeneous in the project.
• Starts to be more challenging to learn how to work with the tool and switch between the available types to attend to specific needs. ( for example, a user might see that it is better to address a requirement with helm or ansible and another with Golang. They would then expect a similar/closer behaviour and steps to do the configuration with changes and caveats that are only specific to type/language. Also, for example, to run the project locally and use the CLI features, they would expect to have the same flags for all that is common between them. )
• The complexity to do this sync/update has been increasing exponentially. How long we wait to do that then, more changing will be to address the changes and keep them aligned.

Describe the solution you'd like.

• Align/update Helm/Ansible common configuration files with Golang
• By checking the changes made shows not required to create a new plugin version for helm/ansible. The changes can be addressed in the v1 version and without breaking changes.
• Note that one of the changes made in Golang is: The manager flags --metrics-addr and enable-leader-election now are named --metrics-bind-address and --leader-elect to be more aligned with core Kubernetes Components. More info: (c-r v0.2.0) *: bump controller-runtime to v0.2.0, update APIs #1839. So, it is required to deprecated the old flags for Ansible/Helm and add the new ones and use them by default in the scaffold. It requires changes in the internal code for Ansible/Helm and scaffolds.

Other significant changes to be addressed are:

• A new option to create the projects using ComponentConfig is introduced. For more info see its enhancement proposal and the Component config tutorial
• Makefile Help for Ansible/Helm and its refractories ( see that it was refactored for golang and we might have changes to apply for them as well.)
• Manager manifests now use SecurityContext to address security concerns.

Aditional Context

How to check the differences to do this sync/update?

• diff internal/plugins/ansible/v1/scaffolds/internal/templates/config with https://github.com/kubernetes-sigs/kubebuilder/tree/master/pkg/plugins/golang/v3/scaffolds/internal/templates/config (kb bumped version)
• diff internal/plugins/helm/v1/scaffolds/internal/templates/config with https://github.com/kubernetes-sigs/kubebuilder/tree/master/pkg/plugins/golang/v3/scaffolds/internal/templates/config (kb bumped version)
• diff helm/ansible Makefile with go/v3 Makefile

NOTE: See Plugins Ecosystem Next - Meta issue #2016. Note that the design proposed in Extract config/base plugin valid for any language/type from Golang #2015 can solve this current problem to keep the projects maintainable and aligned in the future.

[estroz]

@camilamacedo86 can you please make separate issues for these things you think need aligning between Go and Ansible/Helm? It's hard to address issues like this because they have so many components, making discussion disjointed. Please close this issue once done.

/triage support

[camilamacedo86]

Hi @estroz,

@camilamacedo86 can you please make separate issues for these things you think need aligning between Go and Ansible/Helm?

The issue/task is : To ensure that ansible/v1 and helm/v1 is aligned with go/v3 as described. I raised a few points that I know that they are not. However, I understand that is part of this issue/task do the diffs and identify all changes as well. So. I am not sure how to split it. However, I am fine if who get it prefers to make many PRs instead of one to address the changes separately after identifying them. Is it make sense?

Then, note that the fact of it be a hard job as its complexity only grows is one of the reasons that in pov makes it be required to get done as soon as possible as well (priority). I am looking for we no longer face this need in the future via the solution proposed in KB Extract config/base plugin valid for any language/type from Golang #2015 and its pre-requirements defined in the meta issue Plugins Ecosystem Next - Meta issue #2016.

[estroz]

The issue/task is : To ensure that ansible/v1 and helm/v1 is aligned with go/v3 as described

This isn't actionable or triage-able since there is no fix for this, and the requirements are ever-changing as each of the Go, Ansible, and Helm plugins adopts changes/fixes/features.

I am not sure how to split it

Take each one of the bullet points above in "Describe the solution you'd like" and make an issue if one doesn't exist already. Be sure to list the changes you're talking about so whoever works on the issue knows what to do. If you don't have a concrete example of what needs changing in Ansible/Helm plugins to align with existing changes in the Go plugin, then I don't see a reason to have an issue in the first place.

[camilamacedo86]

HI @estroz,

In the first comment, I described reasons and motivations for it be required in (A few bad side effects regarding Helm/Ansible starts to deviate from Golang are:) In POV, to solve this issue we need to:

• Diff the plugins and check what are differences
• Very changes that were done for go that still required to be applied for Ansible/Helm (I raised 3 changes that I know about already)
• Then, do the required updates which in POV can be done as you suggested ( spplited in many PR's / issues ).

PS.: I added what directories required to be compared. In the past, I tried to ensure that KB and Ansible/Helm plugins had the templates files and etc with the same name and in the same directory looking to make this process easier in the future. Indeed IMO we can make an agreement until a better design solution is in place (kubernetes-sigs/kubebuilder#2015) that when we bump kb we try already to check the changes and to do the alignment in the same PR unless the PR is too big because we wait too much to do the sync or KB has too many changes.

[camilamacedo86]

I assigned that to me too do this first steps at least and identify what we need to apply to keep all aligned.

[camilamacedo86]

Regarding the changes in the config only

Note that it is a hight effort to be done manually. Then we have already the PRs to apply 1.5 very shaped and prepared to get merged for we introduce the 1.5 kubernetes-sigs/kubebuilder#2060 / sdk alignment #4581.

And then we might able to centralize it with kubernetes-sigs/kubebuilder#2015.
So, I will wait for that before checking it.

[camilamacedo86]

As part of this task we have tracked now:

• - Ansible/Helm add help to the Makefile Ansible/Helm add help to the Makefile #4628 - PR: ansible/helm: add makefile helper #4660
• - Ansible/Helm providing the same flags as Go Ansible/Helm providing the same flags as Go #4627 PR: ansible/helm : align flags and deprecate the old ones #4654
• - Add ComponentConfig for Ansible/Helm Add ComponentConfig for Ansible/Helm #4643
• - Ansible/Helm should also provide the specific Service Account Ansible/Helm should also provide the specific Service Account #4644 PR: ansible/helm - apply the service account #4653
• - ansible/helm: add ssc to not allow root previleges ansible/helm: add ssc to not allow root previleges #4655
• - 🐛 default service monitor configuration to use https kubernetes-sigs/kubebuilder#2065 - deps: bump kubebuilder to 646f742 #4680