<div dir="ltr">In my mind, I thought set_dns would be really an ansible wrapper to system-config launch/dns.py script.<div><br></div><div>But yeah, putting the switch on what's Devstack latest and what's not on an Apache reverse proxy works too.</div><div>The workflow would be similar to what I depicted.</div><div><br></div><div>I think the biggest issue is that DevStack really gives a lot of problems when you try to stack/unstack , so long-lived</div><div>servers are asking for trouble here.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-01 16:36 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">On 2016-08-01 16:08:49 +0200 (+0200), Ricardo Carrillo Cruz wrote:<br>
[...]<br>
<span class="">> The set DNS task would check a file on the puppetmaster which contains the<br>
> state of blue/green DNS records (<a href="http://translate-latest.openstack.org" rel="noreferrer" target="_blank">translate-latest.openstack.org</a> pointing to<br>
> translate_a and <a href="http://translate-soon-to-be-deleted.openstack.org" rel="noreferrer" target="_blank">translate-soon-to-be-deleted.openstack.org</a> pointing to<br>
> translate_b or viceversa) and would only run in case any of the preceding<br>
> create_server tasks did anything.<br>
</span>[...]<br>
<br>
Problem is we can't (okay, shouldn't) automate DNS changes while<br>
we're relying on Rackspace's DNS service, since it's not using a<br>
standard OpenStack API and we really don't want to write additional<br>
tooling to it.<br>
<br>
As mentioned in my earlier E-mail, a simple alternative is to just<br>
update a HTTP 302 (temporary) redirect or a rewrite/proxy to the<br>
"live" deployment in an Apache vhost on <a href="http://static.openstack.org" rel="noreferrer" target="_blank">static.openstack.org</a> or<br>
perhaps update a persistent haproxy pool. Proxying rather than<br>
redirecting probably makes the most sense as we can avoid presenting<br>
IP-address-based URLs to the consumer (and if we're forced to deploy<br>
with TLS then we might be able to stabilize a solution for that at<br>
the proxy too).<br>
<div class="HOEnZb"><div class="h5">--<br>
Jeremy Stanley<br>
<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>