operator
operator copied to clipboard
Provide ability to disable namespace creation
Feature request
It seems that there is no way to prevent the operator from trying to create its own namespace. It would be good if it was possible to turn this behaviour off.
Use case
Two use cases:
- In some RBAC configurations non-admin users do not have the ability to create namespaces.
- If the namespace already exists, it will be overwritten by the operator's namespace. This can cause quite problematic issues if the namespace has been configured with labels, annotations, or other metadata that needs to be retained.
This is something we never gave much thought 😇 🧑💻 . This is a very valid use case.
In some RBAC configurations non-admin users do not have the ability to create namespaces.
i do support this use case. may be we can add a configuration in TektonConfig CRD spec to disable namespace creation.
In addition, we will need to brainstorm all scenarios this will need to support (installation/upgrade/uninstallation...)
If the namespace already exists, it will be overwritten by the operator's namespace. This can cause quite problematic issues if the namespace has been configured with labels, annotations, or other metadata that needs to be retained.
this is a tricky situation. this operator assumes that the targetnamespace and other namespace scoped resources are dispossable (~stateless). ie, it can delete/recreate those resources at will. This is an assumption we follow to make upgrades less flaky (inplace upgrade vs delete-recreate upgrade)
So to support this usecase we have to make sure that we don't make our upgrades less stable or less predictable.
cc @sm43
this is a tricky situation. this operator assumes that the targetnamespace and other namespace scoped resources are dispossable (~stateless). ie, it can delete/recreate those resources at will. This is an assumption we follow to make upgrades less flaky (inplace upgrade vs delete-recreate upgrade)
It sounds as though you're currently deleting the whole namespace and re-creating? Would it be viable to retrieve the operator's objects by label and delete those under it's control, rather than trying to use the namespace to identify them?
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
with a justification.
Mark the issue as fresh with /remove-lifecycle rotten
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/close
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen
with a justification. Mark the issue as fresh with/remove-lifecycle rotten
with a justification. If this issue should be exempted, mark the issue as frozen with/lifecycle frozen
with a justification./close
Send feedback to tektoncd/plumbing.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
with a justification.
Mark the issue as fresh with /remove-lifecycle rotten
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/close
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen
with a justification. Mark the issue as fresh with/remove-lifecycle rotten
with a justification. If this issue should be exempted, mark the issue as frozen with/lifecycle frozen
with a justification./close
Send feedback to tektoncd/plumbing.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.