Merge lp:~jameinel/juju-core/api-registry-tracks-type into lp:~go-bot/juju-core/trunk
Status: | Work in progress |
---|---|
Proposed branch: | lp:~jameinel/juju-core/api-registry-tracks-type |
Merge into: | lp:~go-bot/juju-core/trunk |
Prerequisite: | lp:~jameinel/juju-core/api-use-register-standard-facade |
Diff against target: |
384 lines (+98/-70) 7 files modified
state/apiserver/common/export_test.go (+13/-0) state/apiserver/common/registry.go (+33/-12) state/apiserver/common/registry_test.go (+29/-42) state/apiserver/root.go (+1/-1) state/apiserver/usermanager/usermanager.go (+2/-9) state/apiserver/usermanager/usermanager_test.go (+2/-2) state/apiserver/watcher.go (+18/-4) |
To merge this branch: | bzr merge lp:~jameinel/juju-core/api-registry-tracks-type |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Juju Engineering | Pending | ||
Review via email: mp+220588@code.launchpad.net |
Description of the change
state/apiserver
This changes the Facades registry so that instead of just tracking the
FacadeFactory functions, it also explicitly tracks the Facade type
itself. The main benefit from doing this is that we have a proper (and
passing) TestDiscardedAP
we are exposing over the API without having to actually instantiate any
of those objects.
While the only specific win today is the test case, the wins for the
longer term are:
1) The ability to walk the whole API and determine all Facade versions
along with all methods that are available.
2) If we so choose, we can restore the "introspect a Root object"
(rpc.Serve vs the new rpc.ServeCaller) and have it go back to doing
exactly what it did with hardcoded types per exposed facade. That was
more code right now, which meant delaying getting API versioning out
there.
3) It helps enforce the norm that (Facade, version) describes exactly 1
type, so we don't accidently do weird things and return variable APIs
based on the "id" of requests.
I don't yet have code that ensures the objects being returned by the
factory exactly match the Type that they've been registered with. It
didn't seem to be a big win given that most places use
RegisterStandar
inferring the type from the function that is handed in.
However, "RegisterFacade
returning interface{} and Type as whatever you want. So if we want a bit
more rigidity, we could add that here.
Unmerged revisions
- 2758. By John A Meinel
-
when merging up we accidentally left 'reflect' import around
- 2757. By John A Meinel
-
Merge up the api-use-
register- standard- facade to bring in the fixes for Upgrader - 2756. By John A Meinel
-
Merged api-use-
register- standard- facade into api-registry- tracks- type. - 2755. By John A Meinel
-
Merged api-use-
register- standard- facade into api-registry- tracks- type. - 2754. By John A Meinel
-
Merge up the removal of all of the compat functions.
- 2753. By John A Meinel
-
reformat according to review feedback.
- 2752. By John A Meinel
-
fix a changed function name
- 2751. By John A Meinel
-
Merge api-use-
register- standard- facade. - 2750. By John A Meinel
-
Merged api-use-
register- standard- facade into api-registry- tracks- type. - 2749. By John A Meinel
-
Now that we have GetFacadeType we can properly test everything is exposed correctly.
We still have to sort out Client and Pinger, but the test suite passes now.
Reviewers: mp+220588_ code.launchpad. net,
Message:
Please take a look.
Description: /common: Registry tracks types
state/apiserver
This changes the Facades registry so that instead of just tracking the IMethods that allows us to introspect everything
FacadeFactory functions, it also explicitly tracks the Facade type
itself. The main benefit from doing this is that we have a proper (and
passing) TestDiscardedAP
we are exposing over the API without having to actually instantiate any
of those objects.
While the only specific win today is the test case, the wins for the
longer term are:
1) The ability to walk the whole API and determine all Facade versions
along with all methods that are available.
2) If we so choose, we can restore the "introspect a Root object"
(rpc.Serve vs the new rpc.ServeCaller) and have it go back to doing
exactly what it did with hardcoded types per exposed facade. That was
more code right now, which meant delaying getting API versioning out
there.
3) It helps enforce the norm that (Facade, version) describes exactly 1
type, so we don't accidently do weird things and return variable APIs
based on the "id" of requests.
I don't yet have code that ensures the objects being returned by the dFacade that explicitly does the registration by
factory exactly match the Type that they've been registered with. It
didn't seem to be a big win given that most places use
RegisterStandar
inferring the type from the function that is handed in.
However, "RegisterFacade (Factory, Type)" does define Factory as
returning interface{} and Type as whatever you want. So if we want a bit
more rigidity, we could add that here.
https:/ /code.launchpad .net/~jameinel/ juju-core/ api-registry- tracks- type/+merge/ 220588
Requires: /code.launchpad .net/~jameinel/ juju-core/ api-use- register- standard- facade/ +merge/ 219670
https:/
(do not edit description out of merge proposal)
Please review this at https:/ /codereview. appspot. com/97630045/
Affected files (+102, -72 lines): /common/ export_ test.go /common/ registry. go /common/ registry_ test.go /root.go /upgrader/ upgrader. go /usermanager/ usermanager. go /usermanager/ usermanager_ test.go /watcher. go
A [revision details]
M state/apiserver
M state/apiserver
M state/apiserver
M state/apiserver
M state/apiserver
M state/apiserver
M state/apiserver
M state/apiserver