-
Notifications
You must be signed in to change notification settings - Fork 251
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
Discussion: Piping information between components #1
Comments
Option 2 seems practical to me. |
Agree, option 2 seems like a good one |
Pursuing Option 2 would require switching the entire platform from asynchronous to synchronous. In this case, instead of using state resolution loops, we will have to do incremental deployments and watch each step. This is more the domain of things like Brigade, and is well outside of the scope for what we planned on doing in Hydra. I would object to 2. I don't think that 3 is within the bounds of the specification. That should be implementation specific. |
@vturecek @technosophos @resouer We currently solve this problem by running a couple of scripts inside the container to pipe the information as well as ensuring the ordering. Yes, it does not require the entire spec compliant platform to change from async to sync. I guess each different platforms can still add its own helper to enable this anyway. But it does make things less clean and consistent. |
When I come back to review this issue, I find this case is exactly match what we proposed here. Hope we could discuss more about it and merge that PR if possible. |
With the introduction of extended workload types, we may need to have a way to pipe the output of components into parameters of other components.Consider the following deployment:
The components are deployed together as part of the same application deployment. Component A will need a connection string to connect to the MySQL database in Component B. However, the connection string is not available until Component B is created.
I can think of a few ways to handle this:
Each option augments the previous in this list, but ultimately some combination of 2 and 3 seems ideal.
The text was updated successfully, but these errors were encountered: