Should retire old stacker_blueprints/postgres.py in favor if stacker_blueprints/rds

[phobologic]

It's just confusing at this point. Need to think about existing examples (empire) that use the old rds.

[awaddell]

Hi @phobologic I had need to provide a MySQL RDS backing-service for apps. I created a mysql.py derived from postgres.py including creating a SG that permits minions instead of controllers however, I can see that it's a fugly move as the MySQL Db now becomes 'required' across all envs and is 99% code duplication anyway.

Do the directions (below) in the base class still apply and are you thinking of something different yourself?

Or perhaps a backing-service should be a standalone stack (but it will then need vpc-id, sg etc)

Should not be used directly. Either use :class:`MasterInstance` or
:class:`ReadReplica` classes, or a engine specific blueprint like
:class:`stacker.blueprints.rds.postgres.MasterInstance` or
:class:`stacker.blueprints.rds.postgres.ReadReplica`.

[phobologic]

Hey @awaddell:

• We actually have a MySQL RDS blueprint already:https://github.com/remind101/stacker_blueprints/blob/master/stacker_blueprints/rds/mysql.py Does that not work for you?
• As far as security groups, one of the ways we've been handling this is by creating a new stack, called 'EmpireMinionSecurityRules' which takes at least 1 (most likely more) parameter - the Minion Security Group from your minion stack. Then you can have it take other parameters (the SG created by your database stack, for example) and have it setup all your rules. I have an example here: https://gist.github.com/phobologic/423ca78c6d9bf012b085#file-example-py (lifted directly from our stacks at Remind, cleaned up a bit) - hope that helps!
• I would suggest following the comment - starting from the base leaves quite a bit of work for you to handle yourself.

That said, I tend to include all of my stacks in the same stacker config, that includes the minions and all the other services (like a database) that they will interact with. I also, in the case of stateful services, tend to set locked to true on any stacks that I do not want to update every time (we hardly ever update our database stack via cloudformation). The benefit is that if you need to spin up a whole new copy of your existing environment (say for development, or staging, or whatever) you know you can do so with confidence.

Hope that helps!

[awaddell]

Hi @phobologic , Thanks for this. I changed to stacker_blueprints.rds.mysql.MasterInstance and implemented your example EmpireMinionSecurityRules successfully though I had to pull out the unneeded SlaveAPIDBSecurityGroup from the class pending working out how to be able to have it absent from the stacker config. Will return to that when not pressed by deadlines.

[phobologic]

Yeah - you don't actually need the Slave Database parameter if you aren't going to use it, was just giving an example of how you could handle mutliple SecurityGroup changes, etc. Let me know if you run into any issues.