Merge lp:~dpb/juju-deployer/api-endpoints into lp:juju-deployer
Proposed by
David Britton
Status: | Merged | ||||
---|---|---|---|---|---|
Merged at revision: | 120 | ||||
Proposed branch: | lp:~dpb/juju-deployer/api-endpoints | ||||
Merge into: | lp:juju-deployer | ||||
Diff against target: |
230 lines (+145/-4) 4 files modified
deployer/env/go.py (+24/-4) deployer/tests/test_goenv.py (+85/-0) deployer/tests/test_utils.py (+22/-0) deployer/utils.py (+14/-0) |
||||
To merge this branch: | bzr merge lp:~dpb/juju-deployer/api-endpoints | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
juju-deployers | Pending | ||
Review via email: mp+230190@code.launchpad.net |
Commit message
Consult juju api-endpoints if using gojuju
Description of the change
Consult juju api-endpoints if using gojuju. Fall back to using the old mechanism of looking at juju status for node 0.
I created a daily build PPA for this as well, so we can make forward progress on testing:
https:/
To post a comment you must log in.
Thanks for the patch.. I have some mixed feelings about using api-endpoints. All api-endpoints is giving us is the addresses. The information we already want is in the the jenv file (credentials, state-servers, and critically the ca-cert to validate the server). There's a class method on the jujuclient Environment to enable connecting using the jenv file given an environment name .connect("foobar"). I'd like to push the logic for trying servers there, and just have deployer call out to it as ideally this should be abstracted for folks at the client library level.