Merge ansible role into monorepo?

[ericfranz]

The first instruction in the README is to:

First pull this repo into where you keep your roles. Shown is the .ansible folder in your home directory.

git clone https://github.com/OSC/ood-ansible.git ~/.ansible/roles/ondemand

If this is the first step, it would seem that if we added the ansible role to the monorepo at the subdirectory ansible we could just alter the directions:

First add this role where you keep your roles. Shown is the .ansible folder in your home directory.

git clone https://github.com/OSC/ondemand.git
git checkout v1.6.20
cp -r ondemand/ansible ~/.ansible/roles/ondemand

Or even

svn export https://github.com/OSC/ondemand/tags/v1.6.20/ansible ~/.ansible/roles/ondemand

The two draw backs I see are that the role is not a git repo so you can't just cd into it and update it - but if you are checking out a specific tag of the role, that is going to be immutable anyways, so the process above could just replace it. The other is that maybe this doesn't play well with some patterns like using ansible-galaxy but I don't know much about those tools.

I know that typically ansible roles are kept in separate repos, but typically so are ruby gems and so are web apps etc. Following the convention of separate repos and enjoying the benefit of being able to clone just that app or component to work on was the same rationale for not having a monorepo all this time.

What are the other drawbacks?

[ericfranz]

Maybe a better set of questions are, when this is moved to the monorepo:

1. What user workflows become impossible?
2. What user workflows become more difficult?
3. Does our target audience care about these drawbacks?

[johrstrom]

Can you git-submodule a specific directory? I see that as a workflow. Like the UAB folks being able to just submodule this repo.

It looks like Galaxy knows to pull the tar from github. And my guess is that we'd likely want to publish there eventually.

[jeff@localhost ondemand]$ ansible-galaxy install geerlingguy.redis
- downloading role 'redis', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-redis/archive/1.6.0.tar.gz
- extracting geerlingguy.redis to /home/jeff/.ansible/roles/geerlingguy.redis
- geerlingguy.redis (1.6.0) was installed successfully

I think other than manually pulling the repo, as you've identified, these are the other two workflows we'd have to be concious of. I've used submoduling repos before, and I suspect galaxy is a fairly legit way to share roles.

[treydock]

I know very little about Ansible so this is in context of Puppet and dealing with configuration management in that context.

When dealing with Puppet the tools to manage modules like r10k expect each repo to be a module and the root of the git repo is the module root. There are ways around this if you build modules for the Puppet Forge by hand but then that would prevent people from adding your Git based module to their r10k Puppetfile catalog.

In general I think it's good to keep configuration management and the product being managed in separate repos unless the configuration management is the primary install method for a given production. Since OnDemand primary method is RPMs , I think it best to keep configuration management content out of the OnDemand repo. This is a common pattern I see in many projects where the product and the automations are distinct repos.

[ghost]

Ansible galaxy can pull roles directly from GitHub if you create a "requirements.yml" file in your "roles" directory for you Ansible project. This doesn't require registering your role on the Ansible Galaxy website. There is probably a oneliner for this, you can use instead, but I only use galaxy in relation with Ansible project structures.

ansible-galaxy install -r roles/requirements.yml

Also, if you want the role to be included in your source tree the simplest way is to use git subtrees as they are easy to update and don't require special consideration when cloning a project.