Ansible Galaxy Improvements

Coming from puppet I used to depend on librarian-puppet and sorely miss that with ansible. This proposal would essentially expand upon ansible galaxy cli to provide a better way to install roles and dependencies other than the current comma delimitated file format that only works with galaxy that it offers now.

I think we should create a new galaxyfile.yml or option to be passed into ansible-galaxy install -f galaxyfile.yml that offers a yaml based approach (to replace the commas) to offer a better and more familiar user experience. The yml file could specify a git repository for example, the version, whether or not to update it, the target role locally locally (not sure where galaxy installs these). On github we could specify other github based dependencies in the meta file for the installer to also fetch. This would allow users to maintain forks or create private git based roles.

The galaxyfile could look something like the current module syntax does now:

- galaxy: >
    pgk=gdamjan.uwsgi
    state=latest
- git: >
    repo=https://github.com/gdamjan/ansible-uwsgi
    version=123
    dest=roles/extra
- file: >
    path=local.tar.gz

To make it backwards compatible I think just detect if its yaml or not. If it is, load the new parser, if not use the csv one.

Perhaps also add another option to ansible-playbook that would parse and install galaxyfile during the playbook run so two separate commands do not need initiated. It could also look for a global galaxyfile and run that without needing the extra commands.

In some cases I would always want to run the latest version of all of the roles. So perhaps by adding state=latest, every time the playbook is run with the appropriate arguments or global galaxyfile it would check which roles need updates and fetch them automatically. Using the git based role we can target a commit, branch, or tag whereas the galaxy we should be able to target version, and file wouldn't have these.

I have never ever used python before but if this is something that would be approved I would be happy to take a shot at this and/or contribute. I think it would make for an awesome feature of ansible 1.6. I would love your feedback on feature suggestions, what direction to go in, and whether or not this would be pulled into core.

Thank you for your time!

(Talked about this on IRC)

Yep the idea for Galaxy’s CLI was definitely to upgrade it over time.

I’m open to this but I think if it’s YAML, it aught to be pure YAML and not do the ansible key=value shortcuts.

What about something like:

roles:

  • { source: galaxy, name: “foo.bar_role”, version: “1234” }
  • { source: git, repo: “…” }
  • { source: file, … }

?

Iteration on the above is fair game.

I think I would rather not have ansible-playbook do this and we should keep it in the ansible-galaxy program.

Also with regard to latest, it seems perhaps easier to just teach ansible-galaxy to do a proper update of this file “ansible-galaxy update” instead of “ansible-galaxy install --force”.

This way we don’t have to contend with the state=latest voodoo and as I am afraid if it looks a lot like Ansible people will then try other things and expect for similar tricks.

–Michael

I was the one talking with you. I decided to bring it here since it is a better platform to discuss in more detail.

I think the pure YAML sounds like a great idea. I felt like comma delimitated flat file is a little bit of a departure from the ansible way but this sounds like a good meet in the middle approach.

As far as implementation goes, here some initial questions since I am not well versed yet in python. Should all functions be contained within the ansible-galaxy bin file? Would it be possible to include and call the GIT based functions in ansible git module? If not, how can we keep things DRY since they would likely have some overlap.

It looks like you download the tar.gz from github right now, so I assume that it is just going to re-install all the roles again regardless if they have updates? I would imagine a mechanism would need to be created to check if an update exists first. Since your dealing with gziped files coming from github, and not directly with git, do you have any thoughts on implementation?

I was the one talking with you. I decided to bring it here since it is a
better platform to discuss in more detail.

I think the pure YAML sounds like a great idea. I felt like comma
delimitated flat file is a little bit of a departure from the ansible way
but this sounds like a good meet in the middle approach.

+1

As far as implementation goes, here some initial questions since I am not
well versed yet in python. Should all functions be contained within the
ansible-galaxy bin file? Would it be possible to include and call the GIT
based functions in ansible git module? If not, how can we keep things DRY
since they would likely have some overlap.

So yes, it's possible.

What we would need to do is move the support functions in the git module to
module_utils/git.py and then we could have galaxy import them.

This is a thing a lot of the modules can start to do to enable reuse,
actually, but we're going to be doing it on a case by case basis.

basic.py is just the starter example that all modules get, see ec2.py and
the like for some others.

It looks like you download the tar.gz from github right now, so I assume
that it is just going to re-install all the roles again regardless if they
have updates? I would imagine a mechanism would need to be created to check
if an update exists first. Since your dealing with gziped files coming from
github, and not directly with git, do you have any thoughts on
implementation?

Not too sure about that one :slight_smile:

Since the ansible-galaxy command is in the core repository for ansible, could you please open a new issue on github to keep track of this request?

As for the update question, the list of available versions are downloaded via the galaxy API, so no tar.gz would be grabbed from github if there is no newer version listed.

Thanks!

Hello James, I did as you suggested but my issue was quickly denied: https://github.com/ansible/ansible/issues/6490. Please let me know where to continue the conversation as I have some questions.

The issues I have so far is that git commands, such as clone for example. It needs the path passed in as well as the module variable. Since the ansible-galaxy command is not a module it can’t make use of the functions to get the git path, pass in the module, etc. So it would need rewritten quite a bit from what I can tell.

I have it pulling in the YAML but not sure how to leverage the other commands.

It wasn’t denied, and we are in fact talking about it right now on IRC :slight_smile:

So I think this is all good and a pull request will be on the way :slight_smile: