You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ConfigMap objects generation is too convoluted: by default, we inject files configuration to a ConfigMap for every file in a _configs service template path, and, if there is an _env.yml.j2 file in a service templates path, we now create a config map that will be considered as environment variables for a service. These conventions add too much complexity/fragility to objects definitions.
Proposal
As we did for routes, I think we must explicitly switch to cm_*.yml.j2 files definitions for every applications/services. A service should be considered as self-consistent: one should NOT read our playbooks to understand which (and how) objects will be created for an application.
The text was updated successfully, but these errors were encountered:
Purpose
ConfigMap objects generation is too convoluted: by default, we inject files configuration to a ConfigMap for every file in a
_configs
service template path, and, if there is an_env.yml.j2
file in a service templates path, we now create a config map that will be considered as environment variables for a service. These conventions add too much complexity/fragility to objects definitions.Proposal
As we did for routes, I think we must explicitly switch to
cm_*.yml.j2
files definitions for every applications/services. A service should be considered as self-consistent: one should NOT read our playbooks to understand which (and how) objects will be created for an application.The text was updated successfully, but these errors were encountered: