-
Notifications
You must be signed in to change notification settings - Fork 222
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
Make trident ready for GitOps / ArgoCD #358
Comments
This issue is similar to #247. |
Testing with latest v20.0.4, the --generate-custom-yaml is still not generating the CSI secret. Was it supposed to be fixed in this release ? |
If using operator, most of the things can be done via ArgoCD, only thing that I am missing is creation of |
@jomeier Could you maybe share your current goals :) ? |
Sure. An operator and its custom resources should 100% take care about that a software does what it is supposed to do. I don't want to call any CLI tool to perform tasks. In the case of Trident we have to create the backend with the CLI tool of trident. This should be not necessary. I don't know other tools/operators that require CLI tools to perform its tasks. Normally - as far as I know operators and I know lots of them - CLI tools only are optional but are not necessary to be called. |
Hi @jomeier, The feature request to add a Trident backend via the Trident Operator is scheduled to be included in the Trident 21.01 release. The tridentctl tool existed prior to Operators being available which is why the functionality to add, update, and remove backends exists in tridentctl. We do plan to make improvements to the Trident Operator going forward but still need to support customers that have created tooling around the tridentctl binary. |
@gnarl: Seeing getting it working together with GitOps tools like ArgoCD is very cool ! Thank you. If it is available and will work, i will close this ticket. |
i stumbled upon this, while i was evaluating how i can fully gitops our cluster infrastructure components (one of those is netapp via trident). Hope 21.01 will come out soon |
We were not able to complete this feature for Trident 21.01. We are continuing work on enabling this feature in a future Trident release. |
Hey @gnarl , do you know which future release will include this feature? |
This issue is fixed with commit 3173b5f and will be included in the Trident 21.04 release. |
Could you point to the doc where samples are provided etc? I can't seem to find them :( |
Hi @travisghansen, Documentation for managing backends: https://netapp-trident.readthedocs.io/en/stable-v21.04/kubernetes/operations/tasks/managing-backends/index.html For new samples (look for YAML-based tbc samples): https://github.com/NetApp/trident/tree/master/trident-installer/sample-input/backends-samples |
Hi,
we are using ArgoCD - a GitOps tool - to configure our OpenShift clusters.
Every application in the cluster is described with YAML files which are in a Git repository. If someone wants to change a configuration of the cluster or manifests of an application running in the cluster he must create a pull request for that. If that PR is approved, the changes get merged in the Git repository. This triggers the GitOps tool (ArgoCD in our case) which applies the new manifests to the Kubernetes cluster.
Currently my problem is that Trident doesn't seem to be ready for it. For sure it creates some YAML files with --generate-custom-yaml but it does not create all manifests it will apply to the cluster on installation.
For instance the secret 'trident-csi' with lots of certificates is not generated. Because of that I can't use the YAML files directly in my Git repo to install trident.
My current workaround is to put a Kubernetes Job manifest in the Git repo which calls tridentctl in a trident container and afterwards it creates a backend by calling tridentctl create backend ... again.
After deletion of this Job from the Git repo some resources of Trident get deleted, some stay in the cluster (like podsecuritypolicy, ...). On the next installation of Trident tridentctl complains about resources already in the cluster and fails ...
I talked with fchuck in the slack channel about that and he told me that a Kubernetes operator for Trident will be available in a few weeks.
Every instance of Trident and each storage backend should be created / deleted by using custom resources, completely without an external command line tool. In this case we could put this CRs in the Git repo and manage Trident configuration / instances with them.
Also the installation/deinstallation of the Trident operator itself should be possible without a command line tool.
Is this possible ?
Thanks and greetings,
Josef
The text was updated successfully, but these errors were encountered: