generated from validatedpatterns/multicloud-gitops
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remake common #4
Merged
mbaldessari
merged 1,794 commits into
validatedpatterns:main
from
mbaldessari:make-common
Sep 6, 2024
Merged
Remake common #4
mbaldessari
merged 1,794 commits into
validatedpatterns:main
from
mbaldessari:make-common
Sep 6, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add help and message clarifying that preview has certain limits
With this the preview all should be a lot more complete and useful. Closes: validatedpatterns/common#452
Add clustergroup support to preview target
…name attribute This covers the following case: foobar: name: foo namespace: foo project: foo path: charts/all/foo The preview.sh script is passed the name attribute of the application `foo`. So now we first find the key which corresponds to the attribute name `foo` and then use that when looking up the other attributes like path, etc. Closes: validatedpatterns/multicloud-gitops#351
Fix preview when the application's index name is not the same as the name attribute
Otherwise if we pass a boolean in the extraParametersNested we will get: spec.source.helm.parameters[10].value: Invalid value: "boolean": spec.source.helm.parameters[10].value in body must be of type string: "boolean"
Force strings in extraParametersNested
The reason for this is the following: When changing the repo on the hub (by editing the pattern), the expectation is that the repo change will replicate from the hub to the spokes managed by ACM. Today this is very unlikely to happen because changing the repo on the hub will not change the policy and so ACM will not reapply it on the spokes. (I believe there is like a daily repush that happens even when the policy has not changed, but that is way too slow to be relied upon). By using the actual variable the policy will actually change, ACM will notice this and push the change on the spokes. Found while testing disconnected mode. I am not replacing them everywhere because I am not sure yet if there are additional semantics in common/clustergroup that I am unaware of.
In ACM policies do not use $ARGOCD_APP_SOURCE_* variables
This feature relies on the VP operator version >= 0.0.44 in order to work. The way to enable this is to add a feature flag called 'initcontainers' in the VP operator. Once this is enabled, we will detect this and take over the all ArgoCD instances' definition and add initContainers which will inject the CAs contained in the trusted-bundle-ca configmap and also the openshift internal CA. Testing protocol: 1. (Operator 0.0.44) MCG deployment with experimentalCapabilities set to '' and using a github main upstream (i.e. without this PR) 2. (Operator 0.0.44) MCG deployment with experimentalCapabilities set to 'initcontainers' and using a github diconnected common upstream (requiring a custom CA) (i.e. with this PR) 3. (Operator 0.0.44) MCG deployment with experimentalCapabilities set to '' and using a github diconnected common upstream. (same as 1.2) and then set the initcontainer capability on the hub. Checked that the .global.experimentalCapabilities property replicated from hub to spoke and the initcontainers have been generated correctly 3.1 (Operator 0.0.44) Change the repo from github to an internal one that does need the custom ca to work 4. (Operator 0.0.43) Test an old operator with a newer common that contains this very branch Note: Once we will make initcontainers a default feature of the operator we will remove the ifs added in this PR and just make it the defaut behaviour.
The changes here support the "Support for merging of namespaces, projects, subscriptions and application in overrides/values-common.yaml #459" issue that was opened by Northrop Grumman Files that were changed are: clustergroup/templates/_helpers.tpl clustergroup/templates/core/namespaces.yaml clustergroup/templates/core/operatorgroup.yaml clustergroup/templates/plumbing/projects.yaml clustergroup/values.schema.json examples/values-example.yaml The idea is that if you define the projects section, or the namespaces section, in two different values files using a map construct we will be able to merge both definition of projects into the final rendering of the manifests. The new structure for projects is as follows: ``` clusterGroup: ... projects: project1: ``` The new structure for namespaces is as follows: ``` clusterGroup: ... namespaces: namespace1: open-cluster-management: labels: openshift.io/node-selector: "" kubernetes.io/os: linux annotations: openshift.io/cluster-monitoring: "true" owner: "namespace owner" ``` The user would need to choose to use a list or a hashmap object. The user would not be able to use a mix of hashes and list to describe projects or namespaces.
Not entirely sure how this slipped in. Reported-by: Martin Jackson <[email protected]>
Drop unused piece of schema json
Custom CA support
Small cleanup to remove unneeded log messages
If the clusterwide proxy object is configured, let's support it when we clone the git repos for the imperative framework.
Support for cluster-wide proxy
Update ESO to 0.9.14
feat: Support for issue #459
Update CRD from operator v0.0.44
Expose main.experimentalCapabilities in operator-install
Release clustergroup v0.8.3
Co-authored-by: Alejandro Villegas <[email protected]> Signed-off-by: Tomer Figenblat <[email protected]>
Co-authored-by: Alejandro Villegas <[email protected]> Signed-off-by: Tomer Figenblat <[email protected]>
Update letsencrypt to v0.1.1
This is needed on spokes when installing in a disconnected environment
A couple of small updated and new releases
Extend the schema for disconnected
Update clustergroup chart to 0.8.12
Update super-linter to v7
Upgrade ESO to v0.10.0
Upgrade vault to 1.17.3
Release new hashicorp-vault and golang-external-secrets charts
It is supported all the way back to OCP 4.12 Tested on sno hub + spoke successfully
Switch to gitops-1.13
See the README for more details, but TLDR: you can use `secret/pushsecrets` to push secrets from any node to the vault. This secret can then be retrieved from either a different namespace or a different cluster node. Tested this with a pushsecret as follows: ``` apiVersion: external-secrets.io/v1alpha1 kind: PushSecret metadata: name: pushsecret namespace: hello-world spec: data: - conversionStrategy: None match: remoteRef: property: baz remoteKey: pushsecrets/testme secretKey: bar deletionPolicy: Delete refreshInterval: 10s secretStoreRefs: - kind: ClusterSecretStore name: vault-backend selector: secret: name: existing-secret updatePolicy: Replace ``` The above takes the property called `baz` of an existing secret called `existing-secret` in the `hello-world` namespace and pushes it to the `secret/pushsecrets/testme` vault path. Suggested-By: Chris Butler <[email protected]> Closes: MBP-641
Add a pushsecrets policy and vault path for ESO syncing
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
install
target