Installation methods have different end results and configuration options

[StianOvrevage]

What steps did you take I jumped into a cluster to look at the existing installation before doing changes. I compared the deployed Kubernetes objects with what a clean install would do.

What happened There was a bunch of differences that I could not understand the reason behind or how it even got in there.

What did you expect to happen: I expected to see the configuration changes we did that differed from the default config.

Findings

Following the instructions in https://open-policy-agent.github.io/gatekeeper/website/docs/install installing https://raw.githubusercontent.com/open-policy-agent/gatekeeper/release-3.7/deploy/gatekeeper.yaml results in a (in my opinion) too different deployment compared to helm: helm template --namespace gatekeeper-system gatekeeper gatekeeper/gatekeeper --version 3.7.1

(Mixing versioning conventions with 3.7 and 3.7.1 also led me to spend some time ensuring that this wasn't a simple versioning issue).

This confusion is probably also what leads an improvement like this: https://github.com/open-policy-agent/gatekeeper/pull/1676 which seems like a good idea in any deployment scenario, to only actually be available when using helm for deployment.

[maxsmythe]

Thanks for the issue!

WRT #1676 I don't think it's necessary in the yaml manifest, since the default value for dnsPolicy is ClusterFirst. When the Helm chart added the ability to set a DNS policy, it added Default as the default value.

In terms of diffs, gatekeeper.yaml is the "raw" config, essentially what gets generated from make manifests whereas Helm has changes that allow for the configuration knobs defined by the chart:

https://github.com/open-policy-agent/gatekeeper/tree/master/charts/gatekeeper

The process for how the Helm chart is built is defined here: https://open-policy-agent.github.io/gatekeeper/website/docs/help/#contributing-to-helm-chart

As such, some diffs would be expected. Let me know if you see any other defaults you think should be in the static manifest.

WRT the differing version conventions...

@chewong Does the new release workflow still have the tag/manifest misalignment?

[chewong]

Mixing versioning conventions with 3.7 and 3.7.1 also led me to spend some time ensuring that this wasn't a simple versioning issue

https://raw.githubusercontent.com/open-policy-agent/gatekeeper/release-3.7/deploy/gatekeeper.yaml contains the manifest for the latest patch release of 3.7.x (right now it's v3.7.2).

If you want a specific version/tag, you can pin the manifests by using https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.7.1/deploy/gatekeeper.yaml.

@chewong Does the new release workflow still have the tag/manifest misalignment?

No, I don't think so. I'd suggest using manifest from either a tag or a release branch though since master branch can be unstable.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.