-
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
[Fleet] Elastic Agent upgrade states UI #167539
[Fleet] Elastic Agent upgrade states UI #167539
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
e654e14
to
1f3a351
Compare
@elasticmachine merge upstream |
@elasticmachine merge upstream |
); | ||
} | ||
|
||
// TODO: check logic |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is something I'm not sure of: we want to show this tooltip if the agent is upgrading but doesn't have upgrade details. Is this check a proper way to do this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed the check to upgrade_started_at:* AND NOT upgraded_at:*
(thanks @juliaElastic).
@ycombinator Could you confirm this is correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This predicate makes sense to me. And I think it's clever to show the tooltip in this scenario (agent is upgrading but we don't have upgrade details) as it encourages users to upgrade to 8.12.
My only feedback would be to somehow not hardcode the 8.12
if possible because we don't know yet when the entire implementation of the upgrade details (including the Agent side of things) will be done. I'm reasonably sure we're on track for 8.12 on the Agent side of things but if, for some odd reason, we don't make that, how can we remember to update this tooltip text? Or perhaps, to be safe, we could pull out just the code for this scenario into a separate PR that we merge at the very end, when we're absolutely sure of the version upgrade details will be available, end-to-end?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree hardcoding the version number is not ideal.
Perhaps a narrow way to be safe could be to define a minVersion
variable, currently undefined
, and only render the tooltip when its value is set. Then, when the changes are ready on Agent side, we would have to remember to open a PR to set the value to 8.12
or another.
@juliaElastic WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, we could create a small gh issue and put in this sprint so we don't forget to set the variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ycombinator I've pushed this change and the other one (no download percent indication in the tooltip if 0) and opened a WIP followup PR to set the version: #168638 that could be merged after the Agent changes are ready.
Could you confirm whether we're ok to merge this PR and add a task to elastic/elastic-agent#3119 to ping Fleet team to merge #168638 when you are ready on your end?
Pinging @elastic/fleet (Team:Fleet) |
id="xpack.fleet.agentUpgradeStatusTooltip.upgradeDownloading" | ||
defaultMessage="Downloading the new agent artifact version ({downloadPercent}%)." | ||
values={{ | ||
downloadPercent: agentUpgradeDetails?.metadata.download_percent, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is download_percent
going to be always populated? If not, maybe we should set 0 if not set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should exist and be populated if the state is UPG_DOWNLOADING
, otherwise I don't think it's set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In saying that, I think it's a really good idea to fall back to 0 in case for some reason the agent doesn't have a download percent. Thanks for the suggesting, will add!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May I suggest that if the download_percent
field is not set OR if it's set to 0, we don't include it in the message? In other words, would it be possible to start including the download percent value in the message only when download_percent > 0
? Otherwise we could end up showing a download percent of 0 to the user for the entire time we're in the UPG_DOWNLOADING
state and then suddenly move to the next state, which might be a bit confusing.
...ublic/applications/fleet/sections/agents/agent_list_page/components/agent_upgrade_status.tsx
Outdated
Show resolved
Hide resolved
...ublic/applications/fleet/sections/agents/agent_list_page/components/agent_upgrade_status.tsx
Outdated
Show resolved
Hide resolved
}, | ||
}, | ||
}); | ||
expectBadgeLabel(results, 'Upgrade failed'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: the tooltip text could be verified for cases where there is a text with variables
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, some minor comments, otherwise 🚀
@@ -295,6 +295,47 @@ export const AGENT_MAPPINGS = { | |||
upgrade_status: { | |||
type: 'keyword', | |||
}, | |||
upgrade_details: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding this comment based on our offline discussion.
This mappings file is there for the only purpose of helping in the KQL validation. It's not adding any new field to the agent index mappings as those live in Elasticsearch repo. I think you'll need to open a separate PR there.
Also, this makes me think that the comment I had on this file is not super clear, so I'll open a small PR to better clarify what's the purpose of this file.
However this is a nice addition because it will enable the KQL searchbox to search on the newly defined fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just checked the existing mappings and noticed that they were added already in this PR elastic/elasticsearch#98680. So you should be good there :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for checking this @criamico! 👍
...ublic/applications/fleet/sections/agents/agent_list_page/components/agent_upgrade_status.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🚢
@juliaElastic @criamico @zombieFox
Thanks all for your feedback! I have one remaining question: FF 8.11.0 was on Oct 3 - should I keep 8.11.0 as the version for this PR (that includes the label text for when the agent has no upgrade details) or should it be changed? |
I don't think this needs to land in 8.11.0 especially since we're still waiting on agent's implementation for this to really be "active" correct? Perhaps we should change this to target 8.12? |
Thanks @kpollich - looking at elastic/elastic-agent#3119 this does seem to make sense. Changing to 8.12.0 unless there are any objections. |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
History
To update your PR or re-run it, just comment with: |
Merging as this is green + approved and Jill is on PTO 🙂 |
## Summary Followup to elastic#167539. Closes elastic/ingest-dev#2568. As the version on which agents will have upgrade details is not known yet, we decided to defer showing the tooltip for agents that don't until it is (cf. elastic#167539 (comment)). This PR sets the version to 8.12. Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
Closes https://github.com/elastic/ingest-dev/issues/1937
This PR implements the UI side of the new Elastic Agent upgrade states.
Note: the following changes will be present regardless of whether Elastic Agent has upgrade details:
Version
columnUpgrade available
text is now a badgeScreenshots
Steps to reproduce
Note: the Elastic Agent changes are not ready yet, so the proposed testing steps aim to mock the upgrade states by editing the agent document(s) manually.
upgrade_started_at
to some timestamp andupgraded_at
tonull
.How to create a "super duper user"
In dev tools, run the following two commands:
Adding upgrade details to an agent
Example commands:
Checklist