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

Define initial well-known interfaces #2650

Open
2 tasks
Tracked by #2678
carolynvs opened this issue Mar 23, 2023 · 0 comments
Open
2 tasks
Tracked by #2678

Define initial well-known interfaces #2650

carolynvs opened this issue Mar 23, 2023 · 0 comments
Labels
pep003-advanced-dependencies Implementation of the Advanced Dependencies proposal placeholder Tracks work that has not yet be fully designed

Comments

@carolynvs
Copy link
Member

carolynvs commented Mar 23, 2023

Are there any interfaces that we can "seed" initially so that people can try out well-known interfaces right off the bat?

Ideas:

  • mysql
  • redis
  • kubernetes

We need to discuss and get consensus on what MUST be on the interface to safely make these types of resources reusable across cloud providers. So we need to understand what someone would reference in a parent bundle that uses any of these as a dependency, such as a connection string.

They should not have parameters or credentials defined, since those will vary significantly between implementations. We should leave those to be unmapped and prompt the user for those values when the dependency is installed.

We have to evaluate these interfaces against known cloud provider implementations, helm charts, and what the software looks like when installed manually (i.e. I installed mongodb directly on my laptop)

Questions

  • Should we always generate individual components of the output, such as host, port, username, password, certs, etc and rely on the consuming parent bundle to use templates to make that into a connection string in the desired format? Or is there a common set of combinations of those values, i.e. connection string format, that they all agree upon across implementations?
  • Can a well-known interface has optional outputs? Where if it's available use it but don't prevent an implementation from being used if not there? I think we could accomplish something similar by allowing a dependency to say that it requires a composite set of interfaces, which isn't in the current design. Do we need that/

ℹ️ Read PEP003 - Advanced Dependencies for context about how dependencies should work, design details, and notes about desired behavior.

@carolynvs carolynvs added pep003-advanced-dependencies Implementation of the Advanced Dependencies proposal placeholder Tracks work that has not yet be fully designed labels Mar 23, 2023
@carolynvs carolynvs changed the title Initial well-known interfaces Define initial well-known interfaces Mar 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pep003-advanced-dependencies Implementation of the Advanced Dependencies proposal placeholder Tracks work that has not yet be fully designed
Projects
No open projects
Status: No status
Development

No branches or pull requests

1 participant