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

Write Concept for Cluster Automation #93

Open
srueg opened this issue Sep 17, 2020 · 1 comment
Open

Write Concept for Cluster Automation #93

srueg opened this issue Sep 17, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@srueg
Copy link
Contributor

srueg commented Sep 17, 2020

Context

Currently we do multiple automated steps when a new cluster is created: a new git repo is created for the catalog, a token is stored in Vault, etc. This will be further extended in the future, for example to save arbitrary secrets in Vault (projectsyn/lieutenant-operator#79), create some CRs to automatically provision cluster via hive or Crossplane, set up authentication provider (e.g. Keycloak), Configure OpsGenie, etc.

Until now all of these features are implemented directly in the lieutenant-operator. Some of these automations are more generic than others and some will most likely only every be used by VSHN.
To make this more extensible and provide a scalable approach to add more automations as the need arises, we need a concept (SDD?) to define where and how such functionality should be implemented.

It should also be part of the concept how to leverage existing operators whenever possible. This includes for example the hive operator or the keycloak-operator.

Some Ideas

  • Create a new operator for each feature (i.e. Vault operator, Keycloak operator, etc.)
  • Create a new operator for all the VSHN specific features (Keycloak, OpsGenie)
  • Implement the features in lieutenant-operator but in a generic way, like we currently do with the GitRepos (GitLab, GitHub, Gitea)

Alternatives

Continue to implement all functionality within the lieutenant-operator. This has the downside that it will become a complex operator which needs to support many different use-cases and might be too VSHN specific.

@srueg srueg added the enhancement New feature or request label Sep 17, 2020
@tobru
Copy link
Contributor

tobru commented Sep 17, 2020

It should also be part of the concept how to leverage existing operators whenever possible. This includes for example the hive operator or the keycloak-operator.

One way to achieve this could be to leverage the upcoming Carpenter Operator, described in SDD 0023 - Managed Services Controller. When a Lieutenant cluster object is created with some conditions, Carpenter could create a new object out of it based on well defined ConditionalObjects object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants