Am 2016-07-25 19:05, schrieb Jeremy Stanley:
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.
Hi Jeremy,
broken DevStack installation - that's the point. With LXD container you
can take snapshot, run unstack or clean script, fetch new code and stack
again. If it failed you can restore the snapshot and try new
installation on another day. Without snapshot you can start new
container with new code and shutdown the old one. So I like the idea
with haproxy in front but wouldn't change any DNS entries because it
takes time for end-users.
If you have enough resources then we can work with 3 VMs: 2 DevStack
installation with translation check-site and one with haproxy hosting
the public FQDN and a kind of trigger to refresh the installation on the
DevStack VM _if_ the other VM is up. If the other DevStack service is
down, the trigger should try an unstack/clean/stack after one day and
switch over if the service is up. This could be done with lb-update
(https://www.haproxy.com/doc/aloha/7.0/haproxy/lbupdate.html) or haproxy
API.
The process should have a small monitoring about the status.
kind regards
Frank
_______________________________________________
OpenStack-Infra mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
