-
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
[WIP] Install argocd and kuadrant in single cluster #1
Conversation
3b99bf0
to
3787efd
Compare
Yeah, kuadrant v0.11.X is not compatible with Sail operator. Reason being, new Istio CRDs deployed by the Sail operator are not known by kuadrant controller and hence it assumes Istio is not installed. Hence, external authorization is not registered in the meshconfig. On v0.12.0, that is about to change. External authorization happens through wasm, so no need to register and configure meshconfig. It is happening in Kuadrant/kuadrant-operator#952. Once merged, kuadrant will work with the Sail operator deployed Istio version. Internal testing and onboarding of the Sail operator in development environment happens in Kuadrant/kuadrant-operator#944 |
project: default | ||
source: | ||
path: manifests/argocd-install | ||
# repoURL: https://github.com/kuadrant/deployment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is that once this merges we will update this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, once the main branch has the actual code, we can point all apps to main.
@@ -0,0 +1,21 @@ | |||
apiVersion: argoproj.io/v1alpha1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this also need to be setup for an OCP cluster?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, in Openshift OLM comes pre-installed. This is just needed for other k8s distributions. We could just install the operators from their manifests (or helm if available) and not use OLM entirely, but OLM provides some features that make upgrading operators a bit safer and I would definitely recommend it for production. For example it checks that all your existing custom resources are compatible with the CRDs that is about to update, which is a crucial step to avoid problems.
argocd.argoproj.io/sync-wave: "-1" | ||
spec: | ||
sourceType: grpc | ||
image: quay.io/kuadrant/kuadrant-operator-catalog:v0.11.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not something needed to be solved right now, but but I wonder how we might keep this in sync with each release of kuadrant itself. Ideally it would always install the latest released version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that once a stable release is hit, there would be a stable
channel that just keeps adding new releases when they are out. If the subscription is set to Automatic
new releases would be installed as soon as they are available in the catalog.
A different concern is to keep gateway-api CRDs and istio in sync. That would require custom logic. If kuadrant-operator provided somehow the version constraints (maybe a configmap?) for Istio and gateway-api we could create a Config Management Plugin for argocd to dynamically determine the versions to install. Same for envoy-gateway.
Just throwing out the idea, haven't really given it much thought ...
hit this error when running the first command
|
Aps, the tmp folder was missing, should work now: Line 50 in 859753c
|
Signed-off-by: Roi Vazquez <[email protected]>
@roivaz got much further this time but still failed on final step
|
@maleck13 testing it with @david-martin he saw that the cloud-provider-kind, which is kind's implementation of a cloud provider to provision local LoadBalancer type Services, is not working properly on macos. I am going to change it and use metallb instead. |
Closing this in favor of #2 |
This PR adds the minimal setup to have a Kuadrant installation managed by argocd in a local kind cluster. ArgoCD manages itself using the app-of-apps pattern and all the Kuadrant related Applications are managed by an ApplicationSet that automatically generates them based on the paths that exist in the GitHub repo under
manifests/kuadrant
.There is an outstanding issue with the installation of Istio using sail-operator, which the kuadrant-operator is not detecting. It seems to be somehow with this work Kuadrant/kuadrant-operator#944 (comment), where similar issues were detected, but right now this installation method is not working properly. I really wanted to use sail here as it is the only install method for Istio that provides upgrade funtionality using GitOps, but we might need to switch to a different one while the issue is not addressed, wdyt @maleck13 ?
Steps to bring up the environment
Issue the following commands in order
make kind-create-cluster-1
make kind-apply-argocd
Open argocd UI in a browser using the url, user and pass shown by the follwing command:
make argocd-url