-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Share Outputs from AWS/AZURE Components with other Components #857
Comments
Love this, @nichtraunzer. Use of ConfigMaps makes absolute sense. Ideally, Terraform outputs marked as sensitive would go into a Secret vs. a ConfigMap. |
Good point ... managing sensitive information ... that requires additional brainpower 🙈 |
@nichtraunzer I assume we would only need to separate sensitive from non-sensitive data within |
I like the idea. Does this mean though that BuildConfigs for components with dependencies will need to be changed by the users to mount the output ConfigMaps coming from preceeding components? |
@albertpuente volume mounts would also need to be part of a deployment descriptor. I like your idea, yet the only benefit I see is that a single shared volume could several files produced by various producers. However, this would require that such a volume does get mounted, otherwise the producer of a file would fail. No? |
If we are strictly speaking of the ods-infra quickstarter, it only comes with a BuildConfig in this case, there is no |
@albertpuente true! On the other hand, consumers would need to ingest the file(s) on the shared volume and apply values at initialisation time. With a ConfigMap, we could have all configurations applied as environment variables, which would be in line with 12-factor apps best practices. We should also consider ease-of-use. |
"OT" - ACK also leverages ConfigMaps for tracking of resources. |
I had a need for this, so I implemented this today (if the solution sounds overall appealing, I see if I find time to contribute back to the QS template):
The chart contains:
a toggle in
Relevant bits:
Produces terraform output and stores JSON in
Produces diff and deploys the chart resources using helm. Importantly, we ware passing
Unfortunately, we need to ensure that
Limitations:
|
Recently we have been contacted from a usecase developer who asks for the following feature:
The current cloud components does not support that feature but I'd like to propose the following solution:
Assuming we have an ODS project X, which contains one AWS component called be (backend), a fronted component fe and an mro component (release manager).
What do you think? Any suggestions or alternative solutions?
(I add an image for better illustration)
The text was updated successfully, but these errors were encountered: