search

cnabio / cnab-spec

Cloud Native Application Bundle Specification
https://cnab.io
Other
950 stars 100 forks source link

Reuse existing installations to satisfy a dependency #426

Closed carolynvs closed 2 years ago

carolynvs commented 2 years ago

The current dependencies spec will always install a new bundle to satisfy a dependency. After talking with users though, there are cases when reusing an existing installation is preferable.

Use Case: Scoped Resource

My micro-services share a common dependency

My application has 4 micro-services and a shared postgres database. When I install the first service, a database should be created for it. When I install the other services, I want to share the database (and the connection string) between them.

We can address this a couple ways:

  1. The runtime decides if there is an installation that could be reused based on criteria.
  2. The runtime allows having an existing installation name used for a dependency (either supplied directly by the user or the tool). This simplifies what is defined in the spec but reduces how much the runtime can help a user when installing bundles.

How each solution impacts how the bundle is modeled:

1

Each micro-service has a dependency on bundle that matches the postgres interface and supplies a default bundle to use if none is provided. The suite of micro-services is represented by a bundle with 4 dependencies on each micro-service.

Any micro-service can be installed separately and the database is automatically created for it. Or they can install the entire suite and they automatically share the database.

2

Each micro-service has a connection string parameter. It is up to the user to pass in a connection string for the appropriate database (i.e. a postgres database instead of something else). The suite of micro-services is represented by a bundle with 5 dependencies: the postgres database and 4 micro-services. The root bundle handles passing the connection string to each of the dependencies.

The entire suite can be installed and they will automatically share a database. When an individual micro-service is installed, the user must supply a connection string to an appropriate database, possibly by figuring out what database bundle to install first, recording the connection string for it after installing and then specifying the connection string parameter to the micro-service bundle.

Which path do we want to go down?

carolynvs commented 2 years ago

Porter is going to support method 1, and will handle determining if an installation can be reused in order to support all the scenarios listed from my original dependencies proposal. It's just a question of what's going into the spec vs. what each tool will support.

carolynvs commented 2 years ago

DataDog's workflow functionality handles passing in outputs from a dependency into another task further down in the workflow.

Sounds like we can go with #2 for simplicity.