juju: remove BootstrapConfig fallback in API connection #5719

Merged
merged 1 commit into from Jul 14, 2016

Conversation

Projects
None yet
2 participants
Owner

rogpeppe commented Jun 26, 2016

This logic is a significant contributor to the complexity
of this code, and it's only there to support a marginal case
that can be addressed otherwise if needed.

The specific case it's there to address is if this sequence of
events happens:

  1. client bootstraps a controller in HA mode.
  2. the initial controller nodes go down and are replaced.
  3. the client tries to connect to the controller.

In this case, the client has no valid addresses for the controller,
but it does have the initial bootstrap configuration so it
can instantiate an Environ instance and use that to find
out the current controller addresses.

This scenario is not a problem if the client has connected any
time when any of the new servers are up.
The logic is no help if the client trying to connect was not
the specific client that originally bootstrapped, because
other clients don't have the bootstrap configuration available.

Given the relatively unlikelyhood of the scenario in general and
that most clients are unlikely to be the ones that actually bootstrapped
the controller, the complexity of the code doesn't seem warranted.

There are various alternative approaches that could be used if the
scenario really does turn out to be a problem in practice:

  • manually get a controller address from the provider's management
    console and add it to the controllers.yaml file.
  • provide a separate command, say "recover-controller" which could
    be used to try to recover controller addresses.
  • provide a way to make controllers listen on a DNS address associated
    with all the current controller addresses.
  • use a server to keep track of current controller addresses and find
    the addresses from that.

(Review request: http://reviews.vapour.ws/r/5166/)

Owner

rogpeppe commented Jul 14, 2016

$$merge$$

Contributor

jujubot commented Jul 14, 2016

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

Contributor

jujubot commented Jul 14, 2016

Build failed: Does not match ['fixes-1598063', 'fixes-1602732', 'fixes-1595686', 'fixes-1596493', 'fixes-1598049', 'fixes-1600237']
build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8412

Owner

rogpeppe commented Jul 14, 2016

$$JFDI$$

Contributor

jujubot commented Jul 14, 2016

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

Contributor

jujubot commented Jul 14, 2016

Build failed: Tests failed
build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8414

Owner

rogpeppe commented Jul 14, 2016

$$JFDI$$

Contributor

jujubot commented Jul 14, 2016

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

juju: remove BootstrapConfig fallback in API connection
This logic is a significant contributor to the complexity
of this code, and it's only there to support a marginal case
that can be addressed otherwise if needed.

The specific case it's there to address is if this sequence of
events happens:

1) client bootstraps a controller in HA mode.
2) the initial controller nodes go down and are replaced.
3) the client tries to connect to the controller.

In this case, the client has no valid addresses for the controller,
but it does have the initial bootstrap configuration so it
can instantiate an Environ instance and use that to find
out the current controller addresses.

This scenario is not a problem if the client has connected any
time when any of the new servers are up.
The logic is no help if the client trying to connect was not
the specific client that originally bootstrapped, because
other clients don't have the bootstrap configuration available.

Given the relatively unlikelyhood of the scenario in general and
that most clients are unlikely to be the ones that actually bootstrapped
the controller, the complexity of the code doesn't seem warranted.

There are various alternative approaches that could be used if the
scenario really does turn out to be a problem in practice:

- manually get a controller address from the provider's management
console and add it to the controllers.yaml file.

- provide a separate command, say "recover-controller" which could
be used to try to recover controller addresses.

- provide a way to make controllers listen on a DNS address associated
with all the current controller addresses.

- use a server to keep track of current controller addresses and find
the addresses from that.
Contributor

jujubot commented Jul 14, 2016

Build failed: Tests failed
build url: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8417

Owner

rogpeppe commented Jul 14, 2016

$$JFDI$$

Contributor

jujubot commented Jul 14, 2016

Status: merge request accepted. Url: http://juju-ci.vapour.ws:8080/job/github-merge-juju

@jujubot jujubot merged commit 8e2e118 into juju:master Jul 14, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment