<div dir="ltr">How about something like a playbook that runs on puppetmaster periodically doing something like this:<div><br></div><div>create_server_translate_a</div><div>create_server_translate_b<br></div><div>set_dns</div><div><br></div><div>The create_server_translate tasks would be idempotent, i.e. they won't leak servers.</div><div>The set DNS task would check a file on the puppetmaster which contains the state of blue/green DNS records (<a href="http://translate-latest.openstack.org/" target="_blank">translate-latest.openstack.org</a> pointing to translate_a and <a href="http://translate-soon-to-be-deleted.openstack.org/" target="_blank">translate-soon-to-be-deleted.openstack.org</a> pointing to translate_b or viceversa) and would only run in case any of the preceding create_server tasks did anything.</div><div><br></div><div>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.</div><div><br></div><div>The main play from above for recreating them would pick up and create a new server and do the needful from DNS perspective.</div><div><br></div><div>Thoughts?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-25 19:05 GMT+02:00 Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2016-07-25 11:08:35 +0530 (+0530), Vipul Nayyar wrote:<br>
> Honestly, I was also thinking that using containers for implementing<br>
> blue/green deployment would be best for implementing minimal downtime. I<br>
> suggest having a basic run-through of this idea with the community over<br>
> tomorrow's irc meeting should be a good start.<br>
<br>
</span>Waving containers at the problem doesn't really solve the<br>
fundamental issue at hand (we could just as easily use DNS or an<br>
Apache redirect to switch between virtual machines, possibly more<br>
easily since we already have existing mechanisms for deploying and<br>
replacing virtual machines). The issue that needs addressing first,<br>
I think, is how to get new DevStack deployments from master branch<br>
tip of all projects to work consistently at each rebuild interval<br>
or, more likely, to design a pattern that avoids replacing a working<br>
deployment with a broken one along with some means to find out that<br>
redeployment is failing so that it can effectively be troubleshot<br>
post-mortem.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Jeremy Stanley<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-Infra mailing list<br>
<a href="mailto:OpenStack-Infra@lists.openstack.org">OpenStack-Infra@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra</a><br>
</div></div></blockquote></div><br></div>