Refactor operator to support several types of resources + propagate labels #38992
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hugoShaka
force-pushed
the
hugo/operator-label-support
branch
from
093c0bb to
40fb3b8
Compare
strideynet
approved these changes
Mar 6, 2024
| return fmt.Errorf("failed to convert Object into Resource object: %T", obj) | ||
| } | ||
| k8sResource := newKubeResource[K]() | ||
| debugLog.Info(fmt.Sprintf("Converting resource from unstructured to %T", k8sResource)) |
There was a problem hiding this comment.
Nit: it'd be preferable to use structured logging here. The reason you've had to use Sprintf is because they are trying to encourage people to switch to structured logging.
marcoandredinis
approved these changes
Mar 7, 2024
public-teleport-github-review-bot
bot
removed the request for review
from tigrato
tigrato
approved these changes
Mar 7, 2024
…bel propagation I initially just wanted to add label propagation (which is required for OpenSSH and OpenSSHEICE servers). However I ran into an issue: not all Teleport resources implement the `ResourceWithLabels` interface. Basically we have 4 cases: - resources implementing `ResourceWithLabels` (e.g. User, Role, ...) - resources implementing `ResourceWithOrigin` but not `ResourceWithLabels` (e.g. GitHub connector, ProvisionToken, ...) - resources that have been tweaked to implement only the operator `TeleportResource` interface (`LoginRule`) - resources implementing `Resource153` To support all those resoucres, we can either: - edit each resource so they expose the same methods (e.g. ProvisionToken exposes `GetLabels` instead of `GetStaticLabels`) - wrap each ressource in a wrapper that implements the operator TeleportResource interface - add multiple reconcilers, one for each resource kind I don't think it's sane for the operator to force changes on Teleport resources. Especially as those are known to be non consistent. I also don't want the operator to maintain a copy of each resource, this is not viable on the long term. For those reasons I chose the 3rd approach and built 3 reconcilers. Then I deducplicated the code to end up with a generic reconciler that can be tuned by passing an adapter. The adapter is an empty struct that has all the methods to extract the information the operator requires from the resource. The resulting PR is large and heavily uses generics but the amount of logical changes is quite low (the only diff is that we now copy labels). I can walk you through the PR if needed. With this PR, the operator supports properly any resource implementing `types.Resource153`, this will be useful to add `TeleportBotV1` support.
hugoShaka
force-pushed
the
hugo/operator-label-support
branch
from
a86c3ab to
3d55c8a
Compare
Co-authored-by: Noah Stride <[email protected]>
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
|
@hugoShaka See the table below for backport results.
|
hugoShaka
added a commit
that referenced
this pull request
Mar 7, 2024
…abels (#38992) * Refactor operator resource reconciler to support resource153 + add label propagation I initially just wanted to add label propagation (which is required for OpenSSH and OpenSSHEICE servers). However I ran into an issue: not all Teleport resources implement the `ResourceWithLabels` interface. Basically we have 4 cases: - resources implementing `ResourceWithLabels` (e.g. User, Role, ...) - resources implementing `ResourceWithOrigin` but not `ResourceWithLabels` (e.g. GitHub connector, ProvisionToken, ...) - resources that have been tweaked to implement only the operator `TeleportResource` interface (`LoginRule`) - resources implementing `Resource153` To support all those resoucres, we can either: - edit each resource so they expose the same methods (e.g. ProvisionToken exposes `GetLabels` instead of `GetStaticLabels`) - wrap each ressource in a wrapper that implements the operator TeleportResource interface - add multiple reconcilers, one for each resource kind I don't think it's sane for the operator to force changes on Teleport resources. Especially as those are known to be non consistent. I also don't want the operator to maintain a copy of each resource, this is not viable on the long term. For those reasons I chose the 3rd approach and built 3 reconcilers. Then I deducplicated the code to end up with a generic reconciler that can be tuned by passing an adapter. The adapter is an empty struct that has all the methods to extract the information the operator requires from the resource. The resulting PR is large and heavily uses generics but the amount of logical changes is quite low (the only diff is that we now copy labels). I can walk you through the PR if needed. With this PR, the operator supports properly any resource implementing `types.Resource153`, this will be useful to add `TeleportBotV1` support. * Update integrations/operator/controllers/reconcilers/base.go Co-authored-by: Noah Stride <[email protected]> * use structured logging --------- Co-authored-by: Noah Stride <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Mar 27, 2024
) * integrations/operator: Add openSSH and openSSHEICE servers * lint * Update integrations/operator/controllers/resources/openssheiceserverv2_controller.go Co-authored-by: Marco André Dinis <[email protected]> * rename Openssh to OpenSSH and fix comments * hide cmdlabels * Refactor operator to support several types of resources + propagate labels (#38992) * Refactor operator resource reconciler to support resource153 + add label propagation I initially just wanted to add label propagation (which is required for OpenSSH and OpenSSHEICE servers). However I ran into an issue: not all Teleport resources implement the `ResourceWithLabels` interface. Basically we have 4 cases: - resources implementing `ResourceWithLabels` (e.g. User, Role, ...) - resources implementing `ResourceWithOrigin` but not `ResourceWithLabels` (e.g. GitHub connector, ProvisionToken, ...) - resources that have been tweaked to implement only the operator `TeleportResource` interface (`LoginRule`) - resources implementing `Resource153` To support all those resoucres, we can either: - edit each resource so they expose the same methods (e.g. ProvisionToken exposes `GetLabels` instead of `GetStaticLabels`) - wrap each ressource in a wrapper that implements the operator TeleportResource interface - add multiple reconcilers, one for each resource kind I don't think it's sane for the operator to force changes on Teleport resources. Especially as those are known to be non consistent. I also don't want the operator to maintain a copy of each resource, this is not viable on the long term. For those reasons I chose the 3rd approach and built 3 reconcilers. Then I deducplicated the code to end up with a generic reconciler that can be tuned by passing an adapter. The adapter is an empty struct that has all the methods to extract the information the operator requires from the resource. The resulting PR is large and heavily uses generics but the amount of logical changes is quite low (the only diff is that we now copy labels). I can walk you through the PR if needed. With this PR, the operator supports properly any resource implementing `types.Resource153`, this will be useful to add `TeleportBotV1` support. * Update integrations/operator/controllers/reconcilers/base.go Co-authored-by: Noah Stride <[email protected]> * use structured logging --------- Co-authored-by: Noah Stride <[email protected]> --------- Co-authored-by: Marco André Dinis <[email protected]> Co-authored-by: Noah Stride <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changelog: The operator now supports setting labels on Teleport resources. Labels are copied from the Kubernetes CR.
I initially just wanted to add label propagation (which is required for OpenSSH and OpenSSHEICE servers).
However I ran into an issue: not all Teleport resources implement the
ResourceWithLabelsinterface.Basically we have 4 cases:
ResourceWithLabels(e.g. User, Role, ...)ResourceWithOriginbut notResourceWithLabels(e.g. GitHub connector, ProvisionToken, ...)TeleportResourceinterface (LoginRule)Resource153To support all those resoucres, we can either:
GetLabelsinstead ofGetStaticLabels)I don't think it's sane for the operator to force changes on Teleport resources. Especially as those are known to be non consistent. I also don't want the operator to maintain a copy of each resource, this is not viable on the long term.
For those reasons I chose the 3rd approach and built 3 reconcilers. Then I deducplicated the code to end up with a generic reconciler that can be tuned by passing an adapter. The adapter is an empty struct that has all the methods to extract the information the operator requires from the resource.
The resulting PR is large and heavily uses generics but the amount of logical changes is quite low (the only diff is that we now copy labels). I can walk you through the PR if needed.
With this PR, the operator supports properly any resource implementing
types.Resource153, this will be useful to addTeleportBotV1support.