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

POC service and worker cluster #177

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Kidswiss
Copy link
Contributor

@Kidswiss Kidswiss commented Jun 7, 2024

Summary

Implementing control and worker cluster support needs following considerations:

  • Managing multiple kubeconfigs for provider-helm and provider-kubernetes
  • Validation webhooks will need access to the controlcluster
  • We can't keep using connectionDetails like we currently do
    • They can't be written to the worker cluster directly, so they need to be deployed via provider-kubernetes
    • Some helper functions to automatically deploy the the connectiondetails of a given resource via provider-kubernetes would be helpful
  • It's very important to strictly differentiate between managed resources and plain kubernetes objects
    • Unfortunately there are managed objects that don't implement the resource.Managed interface in go, so making the compiler help us with this might be hard
    • ProviderConfigs and Usages are such objects, their golang types don't implement the necessary interface, but they should not be wrapped into kube objects
    • We need to build logic in the runtime to make this as seamless as possible, so that it automatically decides if it's a managed resource or not
      • We might want to get rid of the API that differentiates between those two types and hide it behind a generic function
      • As managed resources are always cluster scoped, it should be possible to detect if any given object should be wrapped or not

Checklist

  • Categorize the PR by setting a good title and adding one of the labels:
    bug, enhancement, documentation, change, breaking, dependency
    as they show up in the changelog
  • Update tests.
  • Link this PR to related issues.

Kidswiss added 2 commits June 6, 2024 15:23
- We'd have to configure and expose the admin account
  - This is done via their cli, so a post install job or something
- We'd have to expose some subset of settings for the end-user
  - allow registration should be off by default -> the instances will
    instantly be available via the internet
Implementing control and worker cluster support needs following considerations:
* Managing multiple kubeconfigs for provider-helm and provider-kubernetes
* Validation webhooks will need access to the controlcluster
* We can't keep using connectionDetails like we currently do
  * They can't be written to the worker cluster directly, so they need to be deployed via provider-kubernetes
  * Some helper functions to automatically deploy the the connectiondetails of a given resource via provider-kubernetes would be helpful
* It's very important to strictly differentiate between managed resources and plain kubernetes objects
  * Unfortunately there are managed objects that don't implement the `resource.Managed` interface in go, so making the compiler help us with this might be hard
  * `ProviderConfigs` and `Usages` are such objects, their golang types don't implement the necessary interface, but they should not be wrapped into kube objects
  * We need to build logic in the runtime to make this as seamless as possible, so that it automatically decides if it's a managed resource or not
    * We might want to get rid of the API that differentiates between those two types and hide it behind a generic function
    * As managed resources are always cluster scoped, it should be possible to detect if any given object should be wrapped or not
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant