bbl up should update dns records

[johannaratliff]

On GCP when bbl up creates a new cloud DNS managed zone X (after a bbl destroy), it doesn't update the X record-set in managed zone Y that uses it.

See bbl issue that suggests fixing this through a concourse task.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/151900699

The labels on this github issue will be updated when the story is started.

[dsabeti]

Hi @JohannaSmith.

This is something we thought about trying to support, but decided there were too many variations of DNS support to manage this generically. For example, which tool you use -- gcloud or aws CLI -- depends on which IaaS you're targeting. DNS setups get even more snowflaky than that. Most teams use some mixture of Route53 and Google DNS, but other teams like CAPI just got new domains altogether. With all of this complication, we decided not to tackle this problem.

When you bbl destroy && bbl up, and a new managed zone gets created with different name servers, where do you need to update the record set? A different GCP managed zone, Route 53, etc?

[johannaratliff]

@dsabeti Yes, a different GCP managed zone Y that referenced the first managed zone X (before it was destroyed) is now out of date with a record set that points to a no longer existing managed zone X. The scope of this issue is only using GCP as our IAAS with no separate DNS considerations.

[rosenhouse]

On routing, we have a DNS zone routing.cf-app.com. We are in the process of consolidation so that:

1. all environments are in the same GCP project
2. our environment DNS is a child of the team DNS, e.g. batman.routing.cf-app.com

With these simplifying assumptions, we're planning to just do some bbl plan-patch magic to make it work.

[dsabeti]

@rosenhouse, my tentative plan for addressing this is to create a new task for setting up DNS (so as not to break the interface for bbl-up), with the requirement that DNS be managed primarily by GCP (more specifically, our task will not try to modify anything in Route53).

[rosenhouse]

that makes sense, although when I think about the lifecycle of the DNS pointer (from parent to new child zone) it has exactly the same lifecycle as the bbl'ed environment itself. So keeping them together might simplify state management and reduce the likelihood of orphans. cc @evanfarrar

also, fwiw, here's a concourse task I threw together today to get this done quick. It runs immediately before the bbl-up task, dropping a new file in the bbl-state dir.

[davewalter]

Closing due to inactivity.