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
Checks results coming from Wanda #987
Conversation
b5e60a3
to
3a326ce
Compare
|
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.
Hey @dottorblaster
Long review hehe
Besides that, I find the next things missing. They can be worked in other PRs, but we should track them:
- Update cluster details page checks result summary box
- Improve the
running
view - Error handling
<ExecutionIcon executionState={executionState} health={health} /> | ||
{label} |
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.
As this is used in the old runner code as well, let's be sure that it doesn't impact the output
executionID={executionID} | ||
hostnames={hostnames} | ||
clusterName={cluster?.name} | ||
onCatalogRefresh={() => { |
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 don't think we need this anymore.
The new catalog doesn't have any difference based on provider.
In any case, in one of the draft PRs, the catalog can be updated using other UPDATE_CATALOG_NEW
type.
PR
return ( | ||
<ExecutionResults | ||
clusterID={clusterID} | ||
executionID={executionID} |
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.
Ok, I like the options of showing specific execution ids, but most probably, by default, we won't have the latest execution ids, so we would need to have some way of getting the latest execution for this cluster using the /api/checks/executions?group_id=#{clusterID}
and fetching the latest one
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.
/api/checks/executions?group_id=#{clusterID}&items_per_page=1
should work if they are ordered as expected (desc by date)
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 checked Wanda code and it looks like they're not ordered https://github.com/trento-project/wanda/blob/main/lib/wanda/executions.ex#L47
Opening a PR for that if it's ok.
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.
There you go trento-project/wanda#93
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.
we won't have the latest execution ids
Absolutely agreed @arbulu89, I'll track the leftover as a subtask in the context of the same user story. We miss the piece where the dashboard actually asks Wanda about the executions.
assets/js/trento.jsx
Outdated
@@ -60,6 +61,10 @@ const App = () => { | |||
path="clusters/:clusterID/checks/results" | |||
element={<ChecksResults />} | |||
/> | |||
<Route | |||
path="clusters/:clusterID/execution/:executionID" |
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.
Maybe better clusters/:clusterID/executions/:executionID
?
We should as well be able to fetch the latest execution. Maybe we could have a "clusters/:clusterID/execution
route for that
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.
As above, we miss that part for now. Changing the route anyway 👍
const hostnames = useSelector((state) => | ||
state.hostsList.hosts.map(({ id, hostname }) => ({ id, hostname })) | ||
); | ||
const cluster = useSelector((state) => |
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.
We already have the getCluster
selector exactly for this
group_id: groupID, | ||
result: resultEnum(), | ||
started_at: '2022-11-09T15:11:31.436586Z', | ||
status: faker.helpers.arrayElement(['running', 'completed']), |
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.
statusEnum maybe?
started_at: '2022-11-09T15:11:31.436586Z', | ||
status: faker.helpers.arrayElement(['running', 'completed']), | ||
timeout: [], | ||
check_results: [ |
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 see a lot of hardcoded values here. Couldn't we use faker to populate them?
Besides that, it would even make sense to have smaller factory functions to build the whole result, as it would give more fleixibility
@@ -0,0 +1,154 @@ | |||
import React from 'react'; |
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.
You need to explain us how this works hehe
It looks super powerful
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 will! I promise 😅
reachable | ||
unreachableMessage="" | ||
> | ||
{checks.map((checkID) => { |
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.
Maybe we can extract that logic, inside the arrow function, inside another component? Seems a little bit convoluted to follow
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.
|
||
export const getHealth = (checkResults, checkID, agentID) => { | ||
const checkResult = checkResults.find(({ check_id }) => check_id === checkID); | ||
if (checkResult) { |
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.
What about an early return here?
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.
- 1 for using a guard here if possible
|
||
const failedExpectationEvaluations = | ||
agentCheckResult?.expectation_evaluations.filter( | ||
(expectationEvaluation) => 'message' in expectationEvaluation |
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 am wondering whether we can look for the type
property.
And I am now realizing our API doc needs improvement in documenting the error scenarios. I'll track it as debt and tackle asap.
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 think that we need to add a type field to the schema that could be error
or result
so we can do this type matching here. Then rename the existing type
fields in error_type
and expectation_type
. This could be done when mapping in the phoenix views, but we need a way to differentiate the oneof basically.
Mapping on the shape looks prone to error in the long run.
P.S. This is good for the first iteration, but please let's keep this on the radar.
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.
Also, you need to filter out the expect_same
expectations till we don't have the new UI or they will show as passing always, and I'd rather to remove them from the count for the first iteration.
2c5a8d7
to
d7e6a97
Compare
@arbulu89 @fabriziosestito @CDimonaco @nelsonkopliku I think I addressed it all, could you see if I missed something? |
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.
@dottorblaster So far so good.
I think we can merge and iterate on the evolution!
}; | ||
}; | ||
|
||
export const getCheckDescription = (catalog, checkID) => |
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.
At the end this is "custom" option for findCheck
in this file.
We could have simply find.Check(catalog, checkID)?.description
I guess.
But well, maybe this is more descritive
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.
No, you're actually right
return checkResults.map(({ check_id }) => check_id); | ||
}; | ||
|
||
export const getHealth = (checkResults, checkID, agentID) => { |
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.
Maybe rename this to getCheckHealthByAgent
or something ?
By the way, he I hate that we should the check state by agent...
It breaks all the logic of our execution payload.
Waiting to update this, we wouldn't need this kind of evaluation functions this way...
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 hate that too 😄 looking forward to a new UX!
return ( | ||
<div> | ||
<Modal | ||
title={catalog?.find(({ id }) => id === selectedCheck)?.description} |
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.
We should use the new getCheckDescription
here
onClose={() => setModalOpen(false)} | ||
> | ||
<ReactMarkdown className="markdown" remarkPlugins={[remarkGfm]}> | ||
{catalog?.find(({ id }) => id === selectedCheck)?.description} |
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.
The same, use getCheckDescription
here
<CheckResult | ||
key={checkID} | ||
checkId={checkID} | ||
description={ |
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.
getCheckDescription
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 like a good starting point to iterate on, indeed.
3df8301
to
6bda1f8
Compare
At +666 I'd like to merge and call this PR THE PULL REQUEST OF THE BEAST |
As above, this PR introduces checks results coming from Wanda.
How was this tested?
Storybook, unit tests