Discussion: Piping information between components
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:
- Component A: replicated workload type with a web app inside a container.
- Component B: extended workload type that creates a MySQL database.
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:
- Require users to manage their own dependencies by deploying components one at a time in the order they want. This is sort of the default that users can do today, but obviously the experience suffers.
- Have a way to specify input and output parameters in the operational deployment config (similar to ARM). General solution that covers more than just connection strings and auth tokens.
- Use an identity management system for auth instead of passing credentials around. This helps with piping of auth information, but doesn't solve for other kinds of information that may need to be passed between components.
Each option augments the previous in this list, but ultimately some combination of 2 and 3 seems ideal.
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.