Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

remove vestigal /admin UI #98

Closed
wmorgan opened this issue Feb 11, 2016 · 1 comment · Fixed by #667
Closed

remove vestigal /admin UI #98

wmorgan opened this issue Feb 11, 2016 · 1 comment · Fixed by #667
Assignees
@olix0r

Comments

@wmorgan
Copy link
Member

wmorgan commented Feb 11, 2016

Functionality is now in /, and things have changed sufficiently that this endpoint doesn't even do anything, just shows a empty UI.
@olix0r
Copy link
Member

olix0r commented Sep 12, 2016

Specifically, the /admin endpoint is useless.

@olix0r olix0r self-assigned this Sep 12, 2016
@olix0r olix0r changed the title remove vestigal /admin UI remove vestigal /admin UI Sep 12, 2016
olix0r added a commit that referenced this issue Sep 14, 2016
@olix0r
Alter Admin initialization to admit plugin-defined handlers
d4de5c4 
Problem

There's no mechanism for plugins to install endpoints onto the admin service.
There should be.

Solution

Introduce the `Admin.WithHandlers` trait, which allows admin initialization to
detect modules that expose handlers.

Refactor Admin initialization to compose handlers during initialization.
Previously, admin classes were subtyped to extend functionality. Now, admin
endpoints are concatenated during initialization so that an arbitrary number of
endpoints may be installed without comabting the type system.

Furthermore, the `Namerd` and `Linker` types now have
configured-but-not-yet-initialized `Admin` values (rather than `AdminConfig`),
so that Admin initialization is congruent with other subsystems.

Finally, remove unused/unwanted parts of admin interface to fix #98.
olix0r added a commit that referenced this issue Sep 14, 2016
@olix0r
Alter Admin initialization to admit plugin-defined handlers
9149979 
Problem

There's no mechanism for plugins to install endpoints onto the admin service.
There should be.

Solution

Introduce the `Admin.WithHandlers` trait, which allows admin initialization to
detect modules that expose handlers.

Refactor Admin initialization to compose handlers during initialization.
Previously, admin classes were subtyped to extend functionality. Now, admin
endpoints are concatenated during initialization so that an arbitrary number of
endpoints may be installed without comabting the type system.

Furthermore, the `Namerd` and `Linker` types now have
configured-but-not-yet-initialized `Admin` values (rather than `AdminConfig`),
so that Admin initialization is congruent with other subsystems.

Finally, remove unused/unwanted parts of admin interface to fix #98.
@olix0r olix0r mentioned this issue Sep 14, 2016
Merged
olix0r added a commit that referenced this issue Sep 15, 2016
@olix0r
Alter Admin initialization to admit plugin-defined handlers (#667)
a78f8b7 
* Alter Admin initialization to admit plugin-defined handlers

Problem

There's no mechanism for plugins to install endpoints onto the admin service.
There should be.

Solution

Introduce the `Admin.WithHandlers` trait, which allows admin initialization to
detect modules that expose handlers.

Refactor Admin initialization to compose handlers during initialization.
Previously, admin classes were subtyped to extend functionality. Now, admin
endpoints are concatenated during initialization so that an arbitrary number of
endpoints may be installed without comabting the type system.

Furthermore, the `Namerd` and `Linker` types now have
configured-but-not-yet-initialized `Admin` values (rather than `AdminConfig`),
so that Admin initialization is congruent with other subsystems.

Finally, remove unused/unwanted parts of admin interface to fix #98.

* make AdminConfig.port optional

* Add a simplistic textual index of handlers.

* naming touchups

* fixup problem introduced by merge conflict
@olix0r olix0r removed the reviewable label Sep 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@olix0r olix0r

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Alter Admin initialization to admit plugin-defined handlers linkerd/linkerd
2 participants
@wmorgan @olix0r