api-endpoints should use the API rather than direct Provider State access
Bug #1268470 reported by
John A Meinel
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
juju-core |
Fix Released
|
High
|
John A Meinel |
Bug Description
Right now the "juju api-endpoints" command goes directly to the environment storage and reads the provider-state file. Instead, it should try to connect to the API itself, and make an RPC request for the endpoints, and only if it fails at doing that should it fall back to using direct provider-state access.
We'll need to confirm if the RPC was available in 1.16, though if the fallback is done well, then it should be straightforward to maintain 1.16 compatibility.
Related branches
lp:~jameinel/juju-core/api-endpoints-from-cache-1268470
- Juju Engineering: Pending requested
-
Diff: 353 lines (+186/-51)4 files modifiedcmd/juju/endpoint.go (+9/-16)
juju/api.go (+63/-23)
juju/apiconn_test.go (+107/-12)
juju/export_test.go (+7/-0)
Changed in juju-core: | |
assignee: | nobody → John A Meinel (jameinel) |
status: | Triaged → In Progress |
Changed in juju-core: | |
milestone: | 1.17.1 → 1.18.0 |
Changed in juju-core: | |
status: | In Progress → Fix Committed |
Changed in juju-core: | |
milestone: | 1.20.0 → 1.19.1 |
Changed in juju-core: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Most of the reason for this command is to help client applications connect as quickly as possible to an api server, doing one-two round trips is just adding latency since the core cli already relies on the value it has cached. Ie. the stateservers value already exist in the jenv file, Core can be responsible for updating that and having an api-servers API to rely on for that purpose. Clients just want to connect as quickly as possible to a server, once they have they can use the api to discover additional endpoints if they care to.