How about something like a playbook that runs on puppetmaster periodically doing something like this:
create_server_translate_a create_server_translate_b set_dns The create_server_translate tasks would be idempotent, i.e. they won't leak servers. The set DNS task would check a file on the puppetmaster which contains the state of blue/green DNS records (translate-latest.openstack.org pointing to translate_a and translate-soon-to-be-deleted.openstack.org pointing to translate_b or viceversa) and would only run in case any of the preceding create_server tasks did anything. Then at $DAYS, we have a cron task that deletes whatever server is blue (or green, none of those colors are my favorites :-), swapping A is Blue/B is green or viceversa. The main play from above for recreating them would pick up and create a new server and do the needful from DNS perspective. Thoughts? 2016-07-25 19:05 GMT+02:00 Jeremy Stanley <[email protected]>: > On 2016-07-25 11:08:35 +0530 (+0530), Vipul Nayyar wrote: > > Honestly, I was also thinking that using containers for implementing > > blue/green deployment would be best for implementing minimal downtime. I > > suggest having a basic run-through of this idea with the community over > > tomorrow's irc meeting should be a good start. > > Waving containers at the problem doesn't really solve the > fundamental issue at hand (we could just as easily use DNS or an > Apache redirect to switch between virtual machines, possibly more > easily since we already have existing mechanisms for deploying and > replacing virtual machines). The issue that needs addressing first, > I think, is how to get new DevStack deployments from master branch > tip of all projects to work consistently at each rebuild interval > or, more likely, to design a pattern that avoids replacing a working > deployment with a broken one along with some means to find out that > redeployment is failing so that it can effectively be troubleshot > post-mortem. > -- > Jeremy Stanley > > _______________________________________________ > OpenStack-Infra mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra >
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
