Lockfile Support

[pgassmann]

Original issue is abandonded in archived galaxy-issues project The related issue about versioning of roles is migrated: https://github.com/ansible/galaxy/issues/83 I recreated this issue in ansible-galaxy and now here.

Original issue by @geerlingguy

It would be helpful if Ansible Galaxy supported a 'lock' file.

When running ansible-galaxy install -r requirements.yml, Ansible Galaxy could create a requirements.lock file (or some other name) that stores the following metadata for each downloaded role:

• Role name
• Role version or branch identifier used
• Specific git tag or hash downloaded

Then, if running the command ansible-galaxy install -r requirements.yml again, it would install based on the exact identifiers in the lock file.

The details could be a little different, of course, and we'd need a command like ansible-galaxy update -r requirements.yml to update an existing lockfile... but this would make idempotent playbook configurations much easier for many projects without requiring all downloaded roles be stored in the project repository (e.g. like Drupal VM currently does).

Other examples of lock file support:

• Python pipfile
• Node.js yarn.lock file
• PHP composer.lock file
• Ruby Gemfile

Original Request

For Drupal VM, we've decided to pin our requirements.yml file's role requirements to specific versions (e.g. 3.0.1, 2.5.0, etc.).

It would be nice if we could support some method of semver with role versions (instead of just requiring a branch or tag... and maybe this is related to/duplicate of #70), where you could specify a dependency in requirements.yml like:

- src: geerlingguy.apache
  version: 1.7.*

When galaxy picks the tag to pull, it would check for any in the 1.7.x range, and choose the latest release. That way I don't have to spend so much time maintaining all my requirements files for various projects.

I would love to see something as involved as Composer's Version support, but I know that's a bit of a moonshot. It would be nice to have a lock file that would set the versions currently installed, too, as that would even allow me to set master but lock in the versions at a specific point in time.

Anyways, I was just thinking about how awesome it is to point at tagged role releases in terms of keeping one's playbook completely idempotent and stable—yet how annoying it is to have to manually tinker with the requirements.yml file so often.

[pgassmann]

For Puppet and Chef, there is similar tooling available and there's already support in Pulp for puppet modules:

• librarian-puppet
• librarian-chef
• Both are based on a common ruby tool: librarian

A useful function is librarian-puppet outdated which shows the difference between the versions in the lock file and the latest version on the forge (would be galaxy)

$ librarian-puppet outdated outdated
puppet-extlib (2.3.1 -> 3.0.0)
puppet-gitlab (2.1.0 -> 3.0.2)
puppet-logrotate (3.3.0 -> 3.4.0)
puppet-mongodb (2.3.0 -> 2.4.1)
puppet-puppetboard (4.1.0 -> 5.0.0)
puppetlabs-apache (3.3.0 -> 3.4.0)
puppetlabs-apt (2.4.0 -> 6.2.1)
puppetlabs-concat (4.2.1 -> 5.1.0)
puppetlabs-inifile (2.3.0 -> 2.4.0)
puppetlabs-mysql (6.1.0 -> 7.0.0)
puppetlabs-ntp (7.2.0 -> 7.3.0)
puppetlabs-postgresql (5.10.0 -> 5.11.0)
puppetlabs-puppetdb (7.0.1 -> 7.1.0)
puppetlabs-stdlib (4.25.1 -> 5.1.0)
puppetlabs-tomcat (2.3.0 -> 2.4.0)
puppetlabs-vcsrepo (2.3.0 -> 2.4.0)
thbe-ssmtp (0.5.12 -> 0.6.0)
theforeman-dhcp (4.1.1 -> 4.2.0)
theforeman-dns (5.3.0 -> 5.3.1)
theforeman-foreman (9.2.0 -> 10.0.0)
theforeman-foreman_proxy (8.0.2 -> 9.0.0)
theforeman-tftp (4.2.0 -> 4.3.0)
unibet-forge_server (0.4.0 -> 0.5.0)

Then you can update individual modules with $ librarian-puppet update thbe-ssmtp theforeman-tftp --verbose

[geerlingguy]

Just noting that of all the questions I get in my day-to-day Ansible work, this is one that comes up quite often ("does Ansible Galaxy have any concept of a lock file?"). I'm assuming with mazer and the new depsolver, it would be a lot easier to implement this sort of functionality.

[tima]

You are correct @geerlingguy. It does not. ansible-galaxy was never designed to be a package manager so it is certain to be lacking when compared to tools in that space. ansible-galaxy is not being further developed -- we have no intention of adding new features to it -- just critical bug fixes and basic maintenance that we have no intention of adding that to ansible-galaxy.

Mazer is intended to be a content package manager and will need a lock file mechanism amongst other features.

[alikins]

There may be a very limited subset of this added for 1.0.

Planning on adding something similar to ansible-galaxy's -r/--role-file support.

Probably something along the lines of a cli flag to point to a yaml file that has a dictionary like the 'dependencies' field of galaxy.yml. ie, a dict mapping collection name to a version spec, {'alikins.collection_inspect': '>=1.0.0', 'alikins.stuff': '2.3.4'}

But I think that should cover a lot of the use cases.