Closed mforsyth closed 8 years ago
Can you remove or make symlinks out of the existing config files? there should be only one copy of each to avoid code rot.
Could you please make the same types of absolutizing paths & lifting config into a single location changes for the slave as I suggested for the master?
Thanks!
@dgrnbrg You asked if we could remove the existing config files. This would leave us with the only example config files in the repo being jinja2 template files containing Ansible-specific variables. It seems like this would make it harder to get started with satellite using any means OTHER than deploying via ansible.
For example, there would no longer be valid config files that you could use to start up the server locally. And if you were using Chef or something, your first step would be to edit a file containing Ansible stuff in it... Pretty opinionated. Still want to move ahead with this?
So, @dgrnbrg any of your comments I didn't respond to, it's a :+1: and I will just make the change... just trying not to exhaust the world's supply of :+1: 's too quickly.
Sounds good.
I understand what you mean about the config files. In that case, could you drastically simplify the ones used in the ansible template, so that they do the absolute bare minimum? That way, there'll be no need to keep them in sync w/ new features.
Yes @dgrnbrg that makes sense. The master config template is already minimal, but the slave template could be stripped down a lot. I'll just leave it so that it only reports free memory by default.
@dgrnbrg OK, I've pushed a version of this which incorporates all of the changes we talked about. I quickly re-tested on my cluster deploying both the systemd and supervisord versions.
@dgrnbrg OK, I added local tasks to build the jars if they aren't already in their expected locations on the workstation... gettin' tighter!
@dgrnbrg done. I also realized that the "command" Ansible module allows for a more concise task for local jar compilation, so I switched to that... and finally added one simple task to ensure that satellite_install_dir exists on the remote hosts in the first place.
@dgrnbrg OK, I just added another variable supervisor_dir to the supervisor Roles, and this directory will contain the supervisor configuration files. The default value of supervisor_dir is a subdirectory of where the Satellite files are installed.
@dgrnbrg Good morning. As you requested, I moved the default variables out of the satellite_master/slave roles and into the example playbook.
LGTM. If you agree, let's merge this!
@dgrnbrg Here's a new PR. The Ansible files have been improved and made into Roles. In addition to the default Roles which supervise via Systemd, there are example Roles that show how to supervise Satellite using Supervisord.
FYI, some more things will need to be changed in order to make any of these Roles available on Ansible Galaxy. For one thing, Galaxy needs each Role to have its own dedicated git repository, with directories that contain Galaxy metadata for that specific Role at the top level of each repo. I'll add a Github issue to eventually create such repositories; not top priority right now.