-
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
Improve consistency of Fleet UI deployment to Kubernetes experience #134747
Comments
Pinging @elastic/fleet (Team:Fleet) |
@joshdover would be great to get your thoughts on this one. The cloud-native team could support getting this through in similar fashion we worked together for #127703 |
@learhy @nick-alayil this is aimed at improving the onboarding from a solution agnostic perspective. |
I'll defer to @kpollich on this, but I don't have any opposition to a contribution. One issue to consider is that we're moving to a new onboarding flow that leads with installing the Agent first, potentially even before an integration has been selected. I don't think this will make sense for k8s deployments because the security requirements of the container need to be known before the k8s manifest is generated. |
@joshdover Is this new onboarding flow coming in 8.4? Should we proceed with updating the Kubernetes experience or wait for your change as it may change the whole layout a lot ? |
I know this issue is for managed Agent but if I'm not mistaken we have a similar flow for the standalone one, right? We have several discussions regarding Hints in standalone Agent at elastic/elastic-agent#613 (comment) which might be related to the flow examined in this issue. @MichaelKatsoulis @kpollich we can sync on this to make sure we head towards one single direction. |
The new onboarding experience is partly in place today, but only when adding your first integration when onboarding on ESS and it still requires choosing the integration first. I believe we already exclude the Kubernetes integration from this new flow. The next stages haven't yet been scheduled (moving integration selection to after agent install), so they won't be coming until 8.5 at the earliest, but likely later. |
This is correct, we exclude a few packages including Kubernetes from the "multi page" onboarding flow: |
@kpollich, @joshdover could be a Visualize data where the OOTB dashboards could be listed. |
hi @MichaelKatsoulis, due to time constraints in the 8.3 iteration we omitted any integration with custom UI elements or steps. The new multi page layout is very much an MVP at the moment. |
@hop-dev @joshdover I've added a comment on the multi-page issue for exploring an infrastructure first approach for hosts. |
cc: @alvarolobato these are the onboarding flow changes we discussed a few weeks back during our sync. |
@mlunadia ++ looking good, this will improve the experience quite a bit. |
this is looking great! Did we explore an option to have the install (step4 for Kubernetes) be part of the step 3 section? the logic is that it would be a bit cleaner if the environment toggles in the step 3 section would affect the UI areas in that section. Cross section UI dependencies work, but if we can avoid it, it would be better, interaction-design-wise. Also, it feels to me that the order could be as this: |
@dimadavid have a look at #136014 and let us know your thoughts.
@MichaelKatsoulis check this comment from @dimadavid to discuss order in #136109 |
Yes, the consolidated step 3 looks way better and feels more streamlined. There are some UI improvements I would make tho. I asked for Figma file if it exists. |
@mlunadia @MichaelKatsoulis Saw this was marked Done on your team's board, can we close this out? |
Closing this as this issue is being tracked elsewhere. https://github.com/elastic/ingest-dev/issues/1269 |
As a continuation of the improvements brought by
a few areas for further improvement have been identified:
The current experience exposes the user to the Kubernetes manifest deployment experience only if the user has selected a policy where Kubernetes has been added as an integration.
The feedback has been that this forces new users to be familiar with how agent policies and integrations work before enabling them to deploy agent to Kubernetes and it is not clear that the Kubernetes integration is required.
This will also solve for security use cases where the Kubernetes integration is not a must.
Requirements:
1. Kubernetes needs to be treated consistently to other types of hosts meaning that it should be a tab option next to Linux, mac, windows, etc..
2. When a user selects a policy that includes the Kubernetes integration, the Kubernetes tab should be preselected by default.
The changes between the daemonset / configmap manifest should remain as handled today.
The text was updated successfully, but these errors were encountered: