Open iameskild opened 1 year ago
Thanks for starting this discussion, @iameskild. Really excited to get this extensions rewrite out the door. Ken and I will be spending some time this week testing all this in preparation for release, at least on the AWS side. Aside from any issues that come out of that, here are some of my thoughts from having worked with the plugins so far.
Make users explicitly determine the stage plugins they want to use instead of registering all plugins that are pip installed
Completely agree with this point. Auto-installing plugins based on what's found in the environment has revealed several logical problems already.
Create Keycloak (auth) provider object (to create new Keycloak clients, roles, etc)
While I agree a reusable component that would serve to configure Keycloak clients and whatnot for downstream plugins would be valuable, my concern with creating a provider (presumably without Terraform) would just lead to reinventing the Terraform provider. Would like to maybe discuss what the failings of the Terraform approach are and brainstorm solutions to those before reinventing any wheels.
nebari destroy
Keycloak stages if the cluster is unavailable or the Keycloak API is inaccessible. Should just be able to skip stages like this anyway since there's no need to deconfigure Keycloak if I'm just destroying the environment anyway.nebari render
capable of generating shared Terraform modules that a Nebari Keycloak class can reference and be reused in plugin stages."Composition over Inheritance"
I think this one is going to be critical for breaking out of the Terraform mold, as the current inheritance based approach coupled with the limitations in managing subcomponents is naturally leading us to a single stage + Terraform lowest common denominator pattern. Being able to more easily split plugins into subcomponents would improve testability and maintainability, as well as expanding options for non-Terraform solutions where appropriate.
Confirm that the DNS auto-provision is working as expected
Suggest maybe moving toward something like External DNS as a more versatile solution. The Cloudflare auto-provision is helpful for my specific case but is overly specific to Cloudflare and can't realistically be expanded to cover other DNS providers without a ton of work.
Other issues/items I'd add to the conversation:
pip install
once, and 2) the name is hard coded in the plugin so multiple instances would conflict anyway. As an example, I'd like to be able to create a generic Helm chart plugin to replace the old helm extensions but lets me fix some of its limitations (namespacing, private repos, secrets, whatever).I'll probably have more to add to this, just wanted to get some initial thoughts down.
Can we start splitting these into individual issues and linking them above. It feels like several of these coould be worked on independently and a few need to be coupled and worked on by one person. This is a good meta issue but have smaller individual tasks should help us divide and conquer and move forward.
Great discussion by the way I like where this is going.
Can we start splitting these into individual issues and linking them above. It feels like several of these coould be worked on independently and a few need to be coupled and worked on by one person. This is a good meta issue but have smaller individual tasks should help us divide and conquer and move forward.
+1, I suggest using GitHub's tasklists - it's a little buggy but convenient to convert tasks into issues as required + track them.
Okay the open tasks have been converted to individual issues.
Originally we also included:
For item one:
init
in #1931 --guided-init
(#1944)For item two:
"Composition over Inheritance"
NebariStage
-->NebariTerraformStage
-->KubernetesInfrastructureStage
). This means there is a higher likelihood of changes that are made to base classes causing breaking changes for their inherited class.render
deploy
destroy