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.

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

Merged
merged 15 commits into from Nov 23, 2022
Merged

Checks results coming from Wanda #987

merged 15 commits into from Nov 23, 2022

Conversation

dottorblaster
Copy link
Contributor

@dottorblaster dottorblaster commented Nov 15, 2022

As above, this PR introduces checks results coming from Wanda.

How was this tested?

Storybook, unit tests

@dottorblaster dottorblaster added the enhancement New feature or request label Nov 15, 2022
@dottorblaster dottorblaster marked this pull request as ready for review November 16, 2022 15:56
@dottorblaster dottorblaster force-pushed the execution-page branch 2 times, most recently from b5e60a3 to 3a326ce Compare November 16, 2022 16:05
@dottorblaster
Copy link
Contributor Author

+555 ATM, sorry for this folks 🥲

Copy link
Contributor

@arbulu89 arbulu89 left a 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}
Copy link
Contributor

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={() => {
Copy link
Contributor

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}
Copy link
Contributor

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

Copy link
Member

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)

Copy link
Member

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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.

@@ -60,6 +61,10 @@ const App = () => {
path="clusters/:clusterID/checks/results"
element={<ChecksResults />}
/>
<Route
path="clusters/:clusterID/execution/:executionID"
Copy link
Contributor

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

Copy link
Contributor Author

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) =>
Copy link
Contributor

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']),
Copy link
Contributor

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: [
Copy link
Contributor

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';
Copy link
Contributor

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

Copy link
Contributor Author

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) => {
Copy link
Member

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

Copy link
Member

@nelsonkopliku nelsonkopliku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tricky one 😄

WANDA_URL=http://localhost:4001 iex -S mix phx.server helped making it run, plus adjusting wanda to make them click.

Then playing a bit with the API I got this result.

checks-execution-page-wanda

With the right set of data I could get a clue of what the output was.

We'll need to iterate on, as usual.


export const getHealth = (checkResults, checkID, agentID) => {
const checkResult = checkResults.find(({ check_id }) => check_id === checkID);
if (checkResult) {
Copy link
Member

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?

Copy link
Member

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
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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_sameexpectations 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.

@dottorblaster
Copy link
Contributor Author

@arbulu89 @fabriziosestito @CDimonaco @nelsonkopliku I think I addressed it all, could you see if I missed something?

Copy link
Contributor

@arbulu89 arbulu89 left a 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) =>
Copy link
Contributor

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

Copy link
Contributor Author

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) => {
Copy link
Contributor

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...

Copy link
Contributor Author

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}
Copy link
Contributor

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}
Copy link
Contributor

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={
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getCheckDescription

Copy link
Member

@nelsonkopliku nelsonkopliku left a 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.

@dottorblaster
Copy link
Contributor Author

At +666 I'd like to merge and call this PR THE PULL REQUEST OF THE BEAST

@dottorblaster dottorblaster merged commit e0aae7b into main Nov 23, 2022
@dottorblaster dottorblaster deleted the execution-page branch November 23, 2022 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

Successfully merging this pull request may close these issues.

None yet

5 participants