-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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.
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
[Discuss] New Management Sections API #43499
Comments
I am out next week so won’t be able to give you comprehensive feedback, but at a high level this sounds great. The app mounting pattern seems super appropriate here, and if you use the context service and such (as the app service does), then you’ll get management page level extensibility as well. My one suggestion is to re-do this issue as a formal RFC PR. The platform team has had success with that format for its service design, it allows for discussions on individual details of the proposal rather than only a single flat thread of comments, and it becomes a sort of permanent documentation to guide development and allow folks to understand how it works and why it works the way it does long after the actual change goes in. |
The Management product visionCC @AlonaNadler @alexfrancoeur @arisonl @skearns64 Historically the Management section has been a kitchen sink. Because we haven't had a clear definition of its purpose or what should go into it, it's accumulated apps over time: Long-term, the ES UI is planning on grouping its apps together into domain-specific "super-apps" (e.g. a Cluster app for cluster management) which will live in the nav drawer, and not in Management. I could imagine something similar done with the other apps here, e.g. an Ingest app that contains Beats Management and Logstash Pipelines, a Security app, perhaps ML jobs could be moved into the ML app, and then you'd just be left with a Kibana Management app. This would be a breaking change for third party apps that ended up in Management, so we would want to target this change for 8.0. The big question is: what's our long-term product vision for the Management app? If it's along the lines of what I've suggested, then we could redirect our efforts into attaining that vision instead of rebuilding Management to support the state it's in now. This would save the AppArch team a lot of work, shifting some work to other teams, and it would advance Kibana as a product. |
As an aside that's a bit contradictory to my above suggestion, Dev Tools functions in a similar way to Management, where it's essentially a shell app with a navigation component that can route to any child app that get registered. It would be amazing if we could create a generic app with this functionality that we could reuse in both places (and possibly others). Even some reusable code (components and services) would be helpful. |
@cjcenizal some of what you've discussed starts to overlap with #37285 and #37283. /cc @peterschretlen |
That's an interesting point; I'll definitely think about whether there's an easy way to separate "subapp mounting" concerns from management-specific ones. I'm sure there's some stuff in there that could be reuseable.
I totally agree @cjcenizal, I think keeping an eye on the long-term product goals is important, and the design here is taking into consideration the links that @kobelb posted above. One question I probably should have answered in more detail is why now? The main driver for considering this now is that the Management API moving to the new platform is going to block other teams from completing migration, so we need to have an answer to what the new platform version of the API looks like as soon as possible in The other question to answer is why not just keep the current API and defer this question until later? The answer to that has to do with the items that are currently used in the management implementation which must be removed in order to migrate to NP: the framework currently registers a This means that we will basically need to rebuild the service anyway in order to migrate to the new platform. So if we are going to invest that time, we might as well invest it in building the API the way we want it to be longer term, rather than creating more work for ourselves later.
Thanks @epixa, I'll see if I can open a PR using that format instead. In the meantime we can keep the conversation flowing here; I'll post a link to the RFC PR when it is ready. |
I also have some thoughts around product use-cases for management vs "super-apps", but that's probably a discussion for a different thread. |
I agree with @cjcenizal that our management is currently a kitchen sink for all capabilities related to stack management alongside space setting and reporting (which is per user), this situation is not ideal and we should definitely improve it. In the past, we briefly bounced ideas about the admin space concept but there was never an urgency so it was postponed. Perhaps now with management API and the new platform, there is a forcing function to decide that. From my perspective, the management app has several goals:
|
Thanks for the input @AlonaNadler! Based on the goals you have described, it seems this proposal is still mostly in line with them, since the scope is really only related to that second bullet point.
This is the one thing we might want to consider, especially if it is something we envision happening nearer-term (by If we think it's a longer-term thing ( This topic might warrant a separate offline discussion with app arch, security, product, and whomever else is interested. I'm going to go ahead and close this issue now, as a proper RFC has been opened which should make reviewing the design easier. Let's continue this conversation over there. |
Background
Management is one of the four primary "domains" covered by @elastic/kibana-app-arch (along with Data, Embeddables, and Visualizations). There are two main purposes for this service:
Purpose
The purpose of this discussion is to consider item 2 above -- the service for registering sections to the nav & loading them up. Below is a proposed design for how this would look in the new platform. The reason for having this discussion now is because some plugins will be blocked on fully moving to the new platform by the management plugin.
Design Goals
Reference
Overview of the legacy service
Example usage of how this looks today:
Current public contracts owned by the legacy service:
Proposed API
This API is influenced heavily by the design of Core's application service mounting. The intent is to make the experience consistent with that service; the Management section is basically one big app with a bunch of registered "subapps".
Example usage:
Detailed design:
Caveats, Questions, & Discussion Points:
Next Steps
We will keep this issue open for feedback for one week (until August 23, 2019), at which point we will seek any final comments before closing the discussion in order to make plans for future implementation.
Copying a few folks here who either have knowledge of the legacy management framework, or who are actively managing plugins that register management sections:
@bmcconaghy @cjcenizal @jen-huang @mattkime @kobelb @legrego @alvarezmelissa87 @peteharverson @mattapperson @stacey-gammon
The text was updated successfully, but these errors were encountered: