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
We currently have a list (increasing in number) on the amount of env variables one can define on the deployment definition for our controllers. There is a well known pattern for defining this key:values via an external primitive resource (e.g. configmap). AFAIK Tekton does the same.
We should consider the above. @gabemontero is this what you had in mind?
The text was updated successfully, but these errors were encountered:
hey @qu1queee yeah both for the controller as is, as well as for anything the upcoming operator might provide, abstracting out the various env vars to be set on the controllers's deployment containers seems like a good next step
and yes a configmap makes sense as the first step
if we want the operator to just manipulate the configmap, or wrapper configmap manipulation in the operator's config object, we can sort that out as @adambkaplan 's work progresses.
Idea:
We currently have a list (increasing in number) on the amount of env variables one can define on the
deployment
definition for our controllers. There is a well known pattern for defining this key:values via an external primitive resource (e.g. configmap). AFAIK Tekton does the same.We should consider the above. @gabemontero is this what you had in mind?
The text was updated successfully, but these errors were encountered: