carolynvs
commented
2 years ago I don't see a scenario where the name used for generated installations would impact cross-tool interoperability.
My preference would be to suggest a naming convention as a non-normative spec, such as PARENT_INSTALLATION_NAME-DEPENDENCY_NAME-RANDOM_SUFFIX. The random suffix is generated similar to the kubernetes resource suffixes, 5 characters long a-z0-9. You could try to get away without using a suffix but then you could potentially collide with user defined installation names.
For example, the myblog bundle has a dependency on a mysql database, so we would take the parent installation name myblog and combine it with the name for the dependency db, resulting in myblog-db-zlv72, where the zlv72 suffix was generated at random to avoid colliding with existing installation names.
dependencies:
requires:
db:
reference: getporter/mysql:v0.1.1
When a dependency is installed, it creates an installation when that bundle is installed. Must that naming convention be defined in the dependencies spec or can it be left up to each tool?
For example, if the wordpress bundle depends up on a mysql bundle what should the name of the mysql bundle's installation be? It would need to be unique so that when the wordpress bundle is installed multiple times, there isn't a naming collision.
What can we do to help an administrator or developer figure out which bundle a dependency "belongs" to? One thought is that we don't need to try to pack everything into the name and could take advantage of installation labels to identify the owner.