Skip to content
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

Open
vturecek opened this issue Jun 13, 2019 · 5 comments
Open

Discussion: Piping information between components #1

vturecek opened this issue Jun 13, 2019 · 5 comments
Labels
Discussion enhancement New feature or request

Comments

@vturecek
Copy link
Member

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:

  1. 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.
  2. 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.
  3. 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.

@vturecek vturecek added Discussion enhancement New feature or request labels Jun 14, 2019
@resouer
Copy link
Member

resouer commented Jul 28, 2019

Option 2 seems practical to me.

@tomkerkhove
Copy link
Contributor

Agree, option 2 seems like a good one

@technosophos
Copy link
Contributor

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.

@xiang90
Copy link
Contributor

xiang90 commented Aug 28, 2019

@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.

@wonderflow
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants