pst
commented
4 years ago 1. How do we envision extending the cluster with custom terraform declarations?
I think it depends on what type of declarations. High level, the goal would need to be to cover the most common configurations with the cluster modules. There may be certain configurations that will require forking and replacing the cluster module. Possibly, as the user community and use-cases grow maybe there will be variants for different use-cases of the cluster modules. Similarly to how I implemented the local dev env with the cluster-local variant of each cluster module.
2. How do we upgrade the kubestack version?
Currently, upgrades require bumping the version in clusters.tf and Dockerfile*. I document specific requirements in the upgrade notes of each release. https://github.com/kbst/terraform-kubestack/releases
The new CLI kbst that provides the local development environment, also has a feature to scaffold new repositories. Similarly, I'd like it to assist in upgrading existing repositories. It does have install, remove and update functionality for manifests from the catalog already.
$ kbst -h
Kubestack Framework CLI
Usage:
kbst [command]
Available Commands:
help Help about any command
local Start a localhost development environment
manifest Add, update and remove services from the catalog
repository Create and change Kubestack repositories
Flags:
-h, --help help for kbst
-p, --path string path to the working directory (default ".")
Use "kbst [command] --help" for more information about a command.3. Should we start implementing outputs similar to the output proposed in #133 ?
I've been avoiding getting into this so far, because I think it should be well thought through and I didn't feel of making that decision alone. I'd appreciate a constructive discussion how to drive this forward in a way that works for the three supported providers and has a decent chance of not needing a breaking change in the next release already.
I envision upgrades being a rather manual process, maybe
git merge upstream, keeping kbst/terraform as the upstream. At the same time I'd envision a singleextensions.tfusing the proposed outputs in order to extend the clusters with custom terraform declarations.
The user repositories are scaffolded from the starters built for each release. The starters are built during release from /quickstart/src. A git merge would not work. That's why I was careful to limit update requirements to changing the versions in clusters.tf and in Dockerfile* and hope to provide a even easier UX with the CLI.
jeacott1
Currently none of the kubestack modules have any outputs. This might make extending the clusters with custom terraform code difficult if one also wishes not to touch the internals in order to provision custom resources around the cluster.
There's a couple questions really:
I envision upgrades being a rather manual process, maybe
git merge upstream, keeping kbst/terraform as the upstream. At the same time I'd envision a singleextensions.tfusing the proposed outputs in order to extend the clusters with custom terraform declarations.