In my mind, I thought set_dns would be really an ansible wrapper to system-config launch/dns.py script.
But yeah, putting the switch on what's Devstack latest and what's not on an Apache reverse proxy works too. The workflow would be similar to what I depicted. I think the biggest issue is that DevStack really gives a lot of problems when you try to stack/unstack , so long-lived servers are asking for trouble here. 2016-08-01 16:36 GMT+02:00 Jeremy Stanley <[email protected]>: > On 2016-08-01 16:08:49 +0200 (+0200), Ricardo Carrillo Cruz wrote: > [...] > > 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. > [...] > > Problem is we can't (okay, shouldn't) automate DNS changes while > we're relying on Rackspace's DNS service, since it's not using a > standard OpenStack API and we really don't want to write additional > tooling to it. > > As mentioned in my earlier E-mail, a simple alternative is to just > update a HTTP 302 (temporary) redirect or a rewrite/proxy to the > "live" deployment in an Apache vhost on static.openstack.org or > perhaps update a persistent haproxy pool. Proxying rather than > redirecting probably makes the most sense as we can avoid presenting > IP-address-based URLs to the consumer (and if we're forced to deploy > with TLS then we might be able to stabilize a solution for that at > the proxy too). > -- > 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
