Trident: Namespace with helm deployment

Created on 12 Feb 2021  路  12Comments  路  Source: NetApp/trident

With manual deployment method documentation says to create dedicated namespace. Which is good. Using helm deployment "default" namespace is used. What's the good practice around that? What's the best way to create dedicated namespace with helm?

Thanks.

enhancement tracked documentation

Most helpful comment

I agree that it shouldn't be in the chart itself. But imho the Trident documentation should encourage best practises such as deploying into a dedicated namespace. From my experience, many people just copy&paste straight from the docs. With the current example in the docs we'll end up with a larger number of installations that don't use a dedicated namespace.

Again, no changes to the chart required. This is purely a doc issue/request to include the additional namespace parameters in the helm install example here: https://netapp-trident.readthedocs.io/en/stable-v21.01/kubernetes/deploying/operator-deploy.html#deploy-the-trident-operator

So instead of

$ helm install <name> trident-operator-21.01.1.tgz

just provide this example:

$ helm install trident ./helm/trident-operator-21.01.0.tgz --namespace trident --create-namespace

All 12 comments

From my perspective, the same best practise should apply. And the example command should simply read

helm install trident ./helm/trident-operator-21.01.0.tgz --namespace trident --create-namespace

(Btw, the docs link to the 21.01.1 release, which doesn't exist (yet)).

With manual deployment method documentation says to create dedicated namespace. Which is good. Using helm deployment "default" namespace is used.

There is no contrast or difference between these two methods. Both deploy to default namespace when namespace isn't specified.

Yes, but I believe the Trident docs should encourage best practises - so a dedicated namespace. If we list example commands, they should include that, imho. So if the current docs could be modified to include the "--namespace trident --create-namespace" parameters in the example command, that would be great.

We actually looked up Helm best practices and the general opinion is that the Helm chart should not create a namespace unless explicitly requested by the user.

I agree that it shouldn't be in the chart itself. But imho the Trident documentation should encourage best practises such as deploying into a dedicated namespace. From my experience, many people just copy&paste straight from the docs. With the current example in the docs we'll end up with a larger number of installations that don't use a dedicated namespace.

Again, no changes to the chart required. This is purely a doc issue/request to include the additional namespace parameters in the helm install example here: https://netapp-trident.readthedocs.io/en/stable-v21.01/kubernetes/deploying/operator-deploy.html#deploy-the-trident-operator

So instead of

$ helm install <name> trident-operator-21.01.1.tgz

just provide this example:

$ helm install trident ./helm/trident-operator-21.01.0.tgz --namespace trident --create-namespace

But imho the Trident documentation should encourage best practises

I think it already does (the best practice mentioned at the top).

What you're really saying is Trident docs should teach people how to use Helm, to save them time. That's fine, but it does bloat the Trident docs making it harder to consume it.

From my experience, many people just copy&paste straight from the docs.

I'm guilty of that too, but I installed Trident with Helm, saw it wasn't in own namespace, googled it and found the answer in seconds. Even though that is wrong (I should have read the Helm docs), it wasn't a problem.

That command example won't work for people who already have that namespace, or who use a different namespace, so it also requires some additional explanation and possibly additional content in the Troubleshooting section.

$ helm install trident helm/trident-operator --namespace trident --create-namespace
Error: cannot re-use a name that is still in use

$ helm install tridentagain helm/trident-operator --namespace trident --create-namespace
Error: rendered manifests contain a resource that already exists. Unable to continue with install: PodSecurityPolicy "tridentoperatorpods" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "tridentagaiun": current value is "trident"

$ helm install trident helm/trident-operator --namespace other-trident --create-namespace
Error: rendered manifests contain a resource that already exists. Unable to continue with install: PodSecurityPolicy "tridentoperatorpods" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-namespace" must equal "other-trident": current value is "trident"

I'm not against the idea of best practices, but I tend to think the Trident docs are already quite extensive and hard to search (because there's already a lot of content in them).

I guess we might agree to disagree on this one. Listing the parameters that would be correct for (likely) at least 95% of all Trident Helm installs is hardly "teach people how to use helm" imho. Also, we currently explicitly list commands for namespace creation in the manual Operator deployment section as well as in the tridentctl section. The Helm install section is the only place we omit that. So if for nothing else, I still believe we should do it for having consistency across our docs for all deployment methods.

I agree that the Trident docs are quite extensive and it often is hard to find the information you are looking for. Though that is a problem of its own and unfortunately I can't think of a better way to organize them.

Not a problem, like I said I wasn't against (and didn't give the idea thumbs down, which I'd do if I disagreed).

Also, we currently explicitly list commands for namespace creation in the manual Operator deployment section as well as in the tridentctl section.

Yes. When writing my previous comment I was going to suggest we should also remove all those instances of hard-coded NS but gave up on it thinking if this ask gets adopted there'd no need to fix those old examples.
I'd glady make a PR with all -n trident eliminated from the docs if the maintainers decide against the proposal, to make the docs consistent. :-) But if this ask goes through, that's fine as well.

OK, let's wait for the higher powers to make a decision :-)

I would second the opinion to include best practices in the trident documentation as this makes a lot of sense to just do it this way by default. If they already have it installed, then I would think 'helm upgrade' would apply vs. helm install.

So instead of:
$ helm install trident-operator-21.01.1.tgz

just provide this example:
$ helm install trident ./helm/trident-operator-21.01.0.tgz --namespace trident --create-namespace

Trident docs have moved to docs.netapp.com. I've created a pull request to propose adding the "--create-namespace" parameter to the example.

See https://github.com/NetAppDocs/trident/pull/38

@wonderland thanks for providing the documentation change. Closing this issue as the documentation change has merged.

Was this page helpful?
0 / 5 - 0 ratings