[OpenStack-Infra] Work toward a translations checksite and call for help

Ricardo Carrillo Cruz ricardo.carrillo.cruz at gmail.com
Mon Aug 1 14:08:49 UTC 2016


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 <fungi at yuggoth.org>:

> 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
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160801/e9a645d2/attachment.html>


More information about the OpenStack-Infra mailing list