As a MySQL DBA, I need to:
- Set up users with permissions on arbitrary databases/tables for various hosts. Ansible=DONE.
- Create databases. Ansible=DONE.
- Create tables in a database with a set of columns, keys and basic permissions. Ansible=NOT DONE(?).
- Slave a machine to a master at an arbitrary binlog name/position using a named user/password. Ansible=NOT DONE(?).
I think given the Ansible Way, this would mean a new “mysql_table” module and “mysql_replication” module?
maybe. I think this could be really interesting if we have some amazing and complete module set to manage MySQL.
That being said, my scripts/applications have always “owned” their own table setup via migration and setup scripts and so on.
I’m not familiar with MySQL replication setup – but maybe that is as simple as templating a config file and starting a service? Might not need a module then. I don’t know.
- consider using group_vars and host_vars for inventory versus vars_files
Apologies, I don’t know what you mean here. I don’t put inventory into vars_files, but rather into /etc/ansible/hosts. Do you mean that I’m defining variables in vars_files that would be perfectly capably defined in the inventory file?
If you have a play that targets a group, and you are doing
vars_files:
Then you can, in the same location as you have /etc/ansible/hosts
Have a YAML file named:
/etc/ansible/group_vars/groupname.yml
which saves you from having to do the vars_files trick(s).
Totally usable in 0.7, but not in 0.6 unless you /also/ have a vars_files section (minor bug)
- use ‘notify’ to restart services only when config files change (you
have a TODO about this somewhere)
The real problem is I’m doing a fairly complex setup of the my.cnf and then potentially modify it outside Ansible’s realm of control - I’m not sure if I’m simply doing it wrong, or if I really am doing something beyond the basic functionality of Ansible. If I can bring the my.cnf postprocessing directly back into control of Ansible, then it will know if the file has changed or not.
Ansible’s no different than any other tools in this regard. If you are editing out of band and the user can also edit some parts of it, the “assemble” module may be a good choice.
There is also a line editing module which is not yet in core – because it needs to be ported over to the new module framework and to be made properly idempotent – though I’ll accept inclusion if/when anyone does update it… that being said, I strongly believe in templates and avoiding that wherever possible.
Or is there some mechanism whereby Ansible detects a file has been changed by external scripts? (I can search mailing list for detail)
Yes and no – if a template or copy operation would have changed the file at the end of the module, the notify kicks in. But there’s not a “has the file, for which I am not specifying what it should be, changed since the last time I ran this”.
- use the get_url module versus shell executing curl
I understand why now people are afraid to OSS their stuff. Very public “duh” moments. 
Nah, hardly…. very hard to drink from the firehose
\
- host an apt repo and use the apt module versus shell executing dpkg
(especially with no creates=)
Unsure if I can foist this overhead onto everyone who wants to try out a distributed database (core project goal: make it as easy to install distributed database as it is today to install single database - if everyone who wanted to try out MySQL had to administer an apt repo to do it, they wouldn’t do it).
Just an idea – I was thinking you could host it, i.e. if I have some ISV software, I can host my own yum repo, and configure people to use it. Was trying to avoid the dpkg command
being executed every time you ran the playbook.
Alternately
dpkg whatever creates=/some/file/that/the/package/will/lay/down
would also work
- not sure what the shell script is for, you could probably get away
with not using it and passing in a location to a variable file using
–extra-vars, perhaps
Which shell script?
Not looking ATM, but there was something in a “SaneAndMinimalSystem” directory somewhere that could have been expressed in modules. Maybe I misunderstood.
And now, my own thoughts.
No-one seemed to express horror at my wrapping up multiple playbooks into a shell script. I had thought that would be a common critique, that I should use playbooks-of-playbooks rather than shell-scripts-calling-playbooks.
I was holding back because I didn’t understand the reason for the script, and kinda suck at reading shell scripts.
I need to generate an SSH keypair and install it everywhere. I do it with supporting scripts. This seems like a task that would be required often, and might be a candidate for a module? Ansible supports modifying the authorized_keys file, but not placing the private key, nor generating the keypair to start with. Wondering if the extra functionality is not desired.
There’s already the authorized_key module, your SSH key generation could happen in a play that only targets 127.0.0.1 and uses the local connection mode, only generating the key if it is not already there, and then you transfer that in subsequent plays?
The shell script is not bad though – (somewhat OT) many people have asked “how do I run make on remote systems” (thinking like someone might do with Fabric). I would generally say that while you can, you don’t… you build it in advance, in Hudson/Jenkins/whatever, and then use Ansible to transfer that content. That is kind of because I just like packages – but more so the general theme that there’s nothing wrong with doing some local steps before you run Ansible.
I wanted to reference a YAML-defined variable:
mysql:
master_user: user1
As {{ mysql[‘master_user’] }} within a template and as $mysql[‘master_user’] within a playbook, but it didn’t work. I changed the variable to just “mysql_master_user: user1” and then I could use the same variable in templates and playbooks. Is this a Really Hard Problem I’ve stumbled onto?
Nah, just something subtle. The shorthand variables don’t really work like Python.
${mysql.master_user} should work fine in the playbook. Presently Jinja2 isn’t allowed in Playbooks (but is in templates), and the shorthand AND Jinja2 are allowed in templates, though I’m thinking about working to turn that back on such that you can use Jinja2 everywhere. In any event, the $shorthand doesn’t use square brackets, it uses “.” for both array and dictionary indexing. The idea being, where possible, I want to avoid things looking like code… (where of course only_if is one place where that doesn’t hold, but I want it to be the only one).