📖 Add ADR on rancher namespace strategy #264
Conversation
Danil-Grigorev
added
the
kind/documentation
Danil-Grigorev
force-pushed
the
namespace-scoped-rancher-adr
branch
3 times, most recently
from
5ee4b94
to
1884b86
Compare
Danil-Grigorev
force-pushed
the
namespace-scoped-rancher-adr
branch
from
1884b86
to
87c300b
Compare
Signed-off-by: Danil Grigorev <danil.grigorev@suse.com>
Danil-Grigorev
force-pushed
the
namespace-scoped-rancher-adr
branch
from
87c300b
to
2bdaeb1
Compare
|
|
||
| The operator will take the responsibility of placing Rancher resources in a specific namespace, defined by the CAPI cluster resource namespace. | ||
|
|
||
| The namespace will only dictate the designated location of the Rancher Manager cluster resources, such as **provisioning.cattle/v1.Cluster** and **management.cattle/v3.ClusterRegistrationToken**. |
There was a problem hiding this comment.
Rancher Turtles at this stage will only create the provisioning.cattle/v1.Cluster instance. It will continue to rely on the Rancher machinery to create the ClusterRegistrationToken.
There was a problem hiding this comment.
Do you think this may have a fallback scenario of creating the token ourselves? It follows the “random” namespace strategy rancher uses.
There was a problem hiding this comment.
Currently we are replicating the UI and token generation is automatic. I'd say we follow that and it that changes in the future we can supercede this version.
There was a problem hiding this comment.
With the current investigation on usage of the managementv3.Cluster to abstract provisioningv1.Cluster it is better to have our priorities stated and clear, in case the behavior would unexpectedly change, or we may loose backwards compatibility.
There was a problem hiding this comment.
The current situation is that we create the provisioningv1.Cluster and so its fine for us to state we will create this in a specific namespace.
We rely on the Rancher machinery to create the ClusterRegistrationToken and as it currently stands the ClusterRegistration token is automatically created in a namespace thats the name of the managementv3.Cluster (that is autogenerated from the provisioningv1.Cluster) . So we will not be creating the ClusterRegistration token and so this should be removed from the ADR.
If we change to generate the managementv3.Cluster in the future then this is cluster scoped and not namespace scoped, so we may need to supercede this ADR at a later date.
|
@Danil-Grigorev - shall we close this and create an updated version when we switch to the v3.Cluster? |
|
I’m closing this as this needs a revisit at a later date with management v3 cluster workflow in mind. |
kind/documentation
What this PR does / why we need it:
This ADR proposes a decision on rancher cluster namespace usage. This will allow rancher turtles to control the created resources location during and after the import process, and allow the operator to have a static set of namespaced RBAC rules.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):A part of rancher/highlander#39
Fixes: #296
Special notes for your reviewer:
Checklist: