Open alikins opened 5 years ago
See also discussions on https://github.com/ansible/proposals/issues/7
And to summarize/tl;dr the first post...
There are (at least) three related problems to solve:
Having a way to have multiple versions of a role or collection 'installed' that doesn't conflict on disk
Having a mechanism to select which of the available installed versions are in use at any given time.
The rules and conventions for updating and managing content with multiple versions. Since multiple versions implies that at least one is not the 'latest', there needs to be a way to express how the pinned versions are managed. Historically, in other pkg mgr like tools, this part gets very complicated very quickly.
Feature Request
For a use case where a project or playbook has a requirements.yml that is specifying versions for roles or collections, if more than one specific version of a collection is installed, mazer will fail.
To support this case, mazer will need some way to allow multiple versions of a collection to be installed at the same time (although, not necessarily in the same content path, but that will be up to implementation).
One of the current design assumptions/requirements for mazer/content path is that there is no support for multiple versions of a content to be installed at the same time. This may need to change.
In combination with the design assumption/requirement that there is only one content path, this means there is no way for mazer to install more than one specific version of a role or collection. This conflicts with some common workflows, including the one suggested by geerlingguy in his ‘how to write a playbook’ talk.
In particular, the suggestions for using a requirements.yml to specify the versions of roles needed for a playbook. If the requirements.yml is used by mazer to install to the default content paths, this will fail attempting to install multiple versions of the same content.
Use Case
What problem does this feature solve? Please describe. A clear and concise description of what the problem is. Ex. I have an issue when [...]
The use case is based on the recommended workflow at https://www.ansible.com/blog/make-your-ansible-playbooks-flexible-maintainable-and-scalable
Proposed Solution
Describe the solution you'd like
There are a couple potential highlevel approaches.
Don't support multiple side-by-side versions at all.
Simplest to implement, but seems like a growing problem. This would need docs/best practices on the best ways to handle similar use as the talk linked above addresses.
Allow multiple content paths (places a set of collections live on disk) to be used, with predictable precedence and name resolution.
This would be similar to the behavior of $PATH environment variables or other ansible paths that support an ordered list of locations ('ROLES_PATH' for ex).
In this approach, each collection path would only include one version of a collection, but since there are multiple collection paths, more 'local' and specific locations could override default locations.
To cover the use cases described above, this may require adding support for CWD or playbook relative collection paths to allow the most specific overrides.
Allow multiple side by side versions of content to be installed in a single collections path
needs a mechanism to avoid install path collisions
~/.ansible/content/geerlingguy/php/6.3.1/roles/php/
~/.ansible/content/geerlingguy/php/latest/roles/php
~/.ansible/content/geerlingguy/php@6.3.1/roles/php
~/.ansible/content/geerlingguy/php/roles/php
Alternatives
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Implementation
Teachability, Documentation, Adoption, Migration Strategy If you can, explain the user story, and possibly provide a version of the docs. Maybe a screenshot or mockup of the design?