Greetings.
The upstream ansible folks have been discussing a 'best practices' doc at: https://github.com/ansible/ansible/blob/devel/docsite/rst/bestpractices.rst
and I have been pondering how we want to setup things on our ansible instance before we add a bunch more things to it.
So, some outstanding questions for comment/discussion:
a) I think I like the idea of splitting out per role trees for things. But we need to decide what level of granularity a 'role' is.
For example, mirrormanager in puppet is a single module. However, it's really:
mirrormanager proxy setup files mirrormanager mirrorlist server web app mirrormanager web app (the admin part) mirrormanager backend scripts (crawler, creating lists, etc)
So, for our purposes should we have mirrormanager all in the same 'role' tree? or should we split it out by functionality?
Many roles won't have this issue, as they will be simpler.
b) What would be the workflow for staging with ansible? Ie, I want to make some config changes only in staging and iron them out and then merge them back to production when ready. Do we copy the role and modify? Do we require only changing vars and seperate files?
Will be thinking on it more, but input welcome.
kevin
On Thu, Feb 21, 2013 at 11:25 PM, Kevin Fenzi kevin@scrye.com wrote:
Greetings.
The upstream ansible folks have been discussing a 'best practices' doc at: https://github.com/ansible/ansible/blob/devel/docsite/rst/bestpractices.rst
and I have been pondering how we want to setup things on our ansible instance before we add a bunch more things to it.
So, some outstanding questions for comment/discussion:
a) I think I like the idea of splitting out per role trees for things. But we need to decide what level of granularity a 'role' is.
For example, mirrormanager in puppet is a single module. However, it's really:
mirrormanager proxy setup files mirrormanager mirrorlist server web app mirrormanager web app (the admin part) mirrormanager backend scripts (crawler, creating lists, etc)
So, for our purposes should we have mirrormanager all in the same 'role' tree? or should we split it out by functionality?
like it too, the 'role' tree. it'd be more productive to go to one place to deal with related stuff.
Many roles won't have this issue, as they will be simpler.
b) What would be the workflow for staging with ansible? Ie, I want to make some config changes only in staging and iron them out and then merge them back to production when ready. Do we copy the role and modify? Do we require only changing vars and seperate files?
How about a dedicated branch for staging where we can merge it into master when ready (just like puppet's) Also, I think git flow coud be a good candidate here to work on a specific 'role' or such. ie, you have staging branch in sync with master, you git flow config start mm_proxy_update, do your cooking, then publish your mm_proxy_update branch, then ansible it for testing. If everything went well, you merge your branch into staging/master depending of the purpose.
Will be thinking on it more, but input welcome.
kevin
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Fri, 22 Feb 2013, Xavier Lamien wrote:
How about a dedicated branch for staging where we can merge it into master when ready (just like puppet's) Also, I think git flow coud be a good candidate here to work on a specific 'role' or such. ie, you have staging branch in sync with master, you git flow config start mm_proxy_update, do your cooking, then publish your mm_proxy_update branch, then ansible it for testing. If everything went well, you merge your branch into staging/master depending of the purpose.
1. we do not have a stagin branch in puppet anymore. Haven't for a good long while
2. I do not think we should do a separate branch like that, at all. I think it makes things hairier than they should be.
3. If we're going to implement staging I think it should be like how puppet is NOW - we duplicate the modules and work on them in there. I know it is not 'the git way' but I think it makes it easier to know where you stand at any given moment and to be sure you are getting the playbooks you expect.
-sv
On Fri, 2013-02-22 at 11:39 -0500, Seth Vidal wrote:
On Fri, 22 Feb 2013, Xavier Lamien wrote:
How about a dedicated branch for staging where we can merge it into master when ready (just like puppet's) Also, I think git flow coud be a good candidate here to work on a specific 'role' or such. ie, you have staging branch in sync with master, you git flow config start mm_proxy_update, do your cooking, then publish your mm_proxy_update branch, then ansible it for testing. If everything went well, you merge your branch into staging/master depending of the purpose.
- we do not have a stagin branch in puppet anymore. Haven't for a good
long while
- I do not think we should do a separate branch like that, at all. I
think it makes things hairier than they should be.
- If we're going to implement staging I think it should be like how
puppet is NOW - we duplicate the modules and work on them in there. I know it is not 'the git way' but I think it makes it easier to know where you stand at any given moment and to be sure you are getting the playbooks you expect.
I'll agree on this, it makes it easier to track the difference between stg and dev and helps make sure that what we do on stg either gets merged or reverted.
Pierre
On Fri, Feb 22, 2013 at 5:39 PM, Seth Vidal skvidal@fedoraproject.orgwrote:
On Fri, 22 Feb 2013, Xavier Lamien wrote:
How about a dedicated branch for staging where we can merge it into master when ready (just like puppet's) Also, I think git flow coud be a good candidate here to work on a specific 'role' or such. ie, you have staging branch in sync with master, you git flow config start mm_proxy_update, do your cooking, then publish your mm_proxy_update branch, then ansible it for testing. If everything went well, you merge your branch into staging/master depending of the purpose.
- we do not have a stagin branch in puppet anymore. Haven't for a good
long while
Well, git is saying me we still do [laxathom@lockbox01 puppet]$ git branch -r origin/FI origin/HEAD -> origin/master origin/fedoracommunity origin/master origin/staging origin/staging-old origin/testing
But indeed, last commit is from Feb, 2012.
Anyhow, they're EOL.
- I do not think we should do a separate branch like that, at all. I
think it makes things hairier than they should be.
- If we're going to implement staging I think it should be like how
puppet is NOW - we duplicate the modules and work on them in there. I know it is not 'the git way' but I think it makes it easier to know where you stand at any given moment and to be sure you are getting the playbooks you expect.
Fair enough.
So, how should we handle the dir. based on kevin proposal like: 'role' dir mirrormanager |-- staging | -- proxy | -- etc
?
______________________________**_________________ infrastructure mailing list infrastructure@lists.**fedoraproject.orginfrastructure@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/**infrastructurehttps://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Fri, 22 Feb 2013 21:13:47 +0100 Xavier Lamien laxathom@fedoraproject.org wrote:
Well, git is saying me we still do [laxathom@lockbox01 puppet]$ git branch -r origin/FI origin/HEAD -> origin/master origin/fedoracommunity origin/master origin/staging origin/staging-old origin/testing
But indeed, last commit is from Feb, 2012.
Anyhow, they're EOL.
I did remove the branch, not sure why it's still showing in your local repo. ;(
So, how should we handle the dir. based on kevin proposal like: 'role' dir mirrormanager |-- staging | -- proxy | -- etc
Not sure. I'm going to noodle up some mockups today or tomorrow and see which ones work best in my mind... and see what others think.
kevin
ok. I finally sat down and poked around at our ansible setup and wrote up some convention ideas and thoughts.
I've marked "FIXME" on those things we need to further figure out, but of course feedback/changes welcome on anything.
kevin --cut-- This file describes some conventions we are going to try and use to keep things organized and everyone on the same page.
If you find you need to diverge from this document for something, please discuss it on the infrastructure list and see if we can adjust this document for that use case.
Playbook naming =============== The top level playbooks directory should contain:
* Playbooks that are generic and used by serveral groups/hosts playbooks * Playbooks used for utility purposes from command line * Groups and Hosts subdirs.
Generic playbooks are included in other playbooks and perform basic setup that is used by other groups/hosts. Examples: cloud setup, collectd, webserver, iptables, etc
Utility playbooks are used by sysadmins command line to perform some specific function. Examples: host update, vhost update, vhost reboot.
The playbooks/groups/ directory should contain one playbook per 'role' or group. This should be used in the case of multiple machines/instances in a role. MUST include a hosts entry that describes the hosts in the group. Examples: packages, proxy, unbound, virthost, etc. Try and be descriptive with the name here.
The playbooks/hosts/ directory should contain one playbook per 'host' for when a role is handled by only one host. Hosts playbooks MUST be FQDN.yml, MUST contain Hosts: the host or ip. Examples: persistent cloud images, special hosts.
Where possible groups should be used. Hosts playbooks should only be used in specific cases where a generic group playbook would not work.
Both groups and hosts playbooks should always include: vars_files: - /srv/web/infra/ansible/vars/global.yml - ${private}/vars.yml
Play naming =========== Plays in playbooks should be a short readable description of what the play is doing. This will be displayed to the user and/or mailed out, so think about what you would like to see if the play you are writing failed that would be descriptive to the reader to help fix it.
Inventory ========= The inventory file should add all hosts to one (or more) groups.
When there are staging hosts for a role/service, they should be in the main group for that role as well as a staging for the role. FIXME: will depend on how we do staging. (see below)
Tags ==== Tags allow you to run just a subset of plays with a specific tag(s).
We have some standard tags we should use on all plays:
packages - this play installs or removes packages.
config - this play installs config files.
check - we could use this tag to include 'is everything running that should be' type tasks.
FIXME: others?
Production vs Staging vs Development ==================================== In the default state, we should strive to have production and staging using the same exact playbooks. development can also do so, or just be a more minimal free form for the developer.
When needing to make changes to test in staging the following process should be used:
FIXME... :)
Requirements:
1. shouldn't touch prod playbook by default 2. should be easy to merge changes back to prod 3. should not require people to remember to do a bunch of steps. 4. should be easy to see exactly what changes are pending only in stg.
Cron job/automatic execution ============================
We would like to get ansible running over hosts in an automated way. A git hook could do this.
* On commit: If we have a way to detemine exactly what hosts are affected by a change we could simply run only on those hosts.
We might want a short delay (10m) to allow someone to see a problem or others to note one from the commit.
* Once a day: (more often? less often?)
We may want to re-run on all hosts once a day and yell loudly if anything changed.
FIXME: perhaps we want a tag of items to run at this time? FIXME: alternately we could have a util playbook that runs a bunch of checks for us?
infrastructure@lists.fedoraproject.org
-
Kevin Fenzi -
Pierre-Yves Chibon -
Seth Vidal -
Xavier Lamien