Skip to content
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

Closed
jomeier opened this issue Mar 19, 2020 · 13 comments
Closed

Make trident ready for GitOps / ArgoCD #358

jomeier opened this issue Mar 19, 2020 · 13 comments

Comments

@jomeier
Copy link

jomeier commented Mar 19, 2020

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

@gnarl gnarl self-assigned this Mar 19, 2020
@gnarl gnarl added the tracked label Mar 19, 2020
@superbrothers
Copy link
Contributor

This issue is similar to #247.

@somejfn
Copy link

somejfn commented May 29, 2020

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 ?

@BostjanBozic
Copy link

If using operator, most of the things can be done via ArgoCD, only thing that I am missing is creation of tridentBackend, as I have no idea how UUIDs are generated.

@Numblesix
Copy link

@jomeier Could you maybe share your current goals :) ?

@jomeier
Copy link
Author

jomeier commented Nov 6, 2020

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.

@gnarl
Copy link
Contributor

gnarl commented Nov 6, 2020

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.

@jomeier
Copy link
Author

jomeier commented Nov 6, 2020

@gnarl:
Thanks for your answer. We are happily looking forward to version 21.01 then. It will save us lots of work and will make the installation of Trident much more simpler.

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.

@Elyytscha
Copy link

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

@gnarl
Copy link
Contributor

gnarl commented Feb 11, 2021

@jomeier,

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.

@DolevAlgam
Copy link

Hey @gnarl , do you know which future release will include this feature?

@gnarl
Copy link
Contributor

gnarl commented Apr 29, 2021

This issue is fixed with commit 3173b5f and will be included in the Trident 21.04 release.

@gnarl gnarl closed this as completed Apr 29, 2021
@travisghansen
Copy link

Could you point to the doc where samples are provided etc? I can't seem to find them :(

@rohit-arora-dev
Copy link
Contributor

rohit-arora-dev commented May 3, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants