In the knowledge sharing session on LocalConfig, there was a bit of confusion about some of the API methods of the gem.
The audience expected LocalConfig::Store#load_namespace! to load configs from kubernetes, which it doesn't actually do. It merely loads a hash into memory. LocalConfig.load_namespaces! on the other hand actually does load configmaps. But it additionally initializes the namespaces (including app, which is not a kubernetes configmap).
Also, the boundaries between namespaces that build on shared kubernetes configmaps, namespaces that are just local objects are hard to grasp.
Furthermore, we might want to distinguish clearly between custom namespaces the app explicitly registers and namespaces that are pre-populated by the gem.
I came up with a proposal in https://github.com/local-ch/local_config/pull/19, which has yet to be confirmed if it's less confusing or not. Maybe it's easier to decide once people start working with it. The gem introduces quite some concepts and conventions. It might get better adopted if the API and wording in the README are clearer.
helm copies the shared configmaps to the dev namespace. Currently, the host application has to add volume mounts manually for every additional configmap the gem loads.
It would be nice to have lcl/helm passing information with kubectl --set (similar to what we have with the default resources). I tinkered with it a little bit, but because we want to append entries to an array it's not as straightforward as with the resources.
I managed to find a solution, but it requires much more logic in the kubernetes template than I'd want to have. Maybe someone who knows the templating language better can improve that: https://github.com/local-ch/web-helm-deploy-plugin/pull/74 https://github.com/local-ch/location-app/pull/2069
As both the application and helm resp. lcl require LocalConfig, we will make sure that the right version (the one from the application) is loaded. Otherwise, there might be a difference in what configmaps the gem from the deploy plugin loads and the application expects. With helm, we can just bundle exec helm deploy to do so, but I don't know how it will work with lcl deploy.
Please keep this in mind!
- implement more shared configmaps
- it would be nice to have a way of versioning configmaps, so existing applications don't die when someone deletes a key from shared configmaps for example. The simplest way to do so would be to include a version number in the name of the configmap.
- once
LocalConfigis stable and adopted, do the same for secrets