Host Check result detail

[nelsonkopliku]

Description

This PR introduces the Check Result detail for a host check execution.

• functionality on the cluster checks execution is kept working as previously
• back and forth navigation from detail to overview is target type aware
• filters are kept between pages

For consistency URL structure for host check detail has been kept the same as cluster check detail

/clusters/:targetID/executions/last/:checkID/:resultTargetType/:resultTargetName
/hosts/:targetID/executions/last/:checkID/:resultTargetType/:resultTargetName

even though in the host context :resultTargetType is always host and :resultTargetName is always the name of the host for which we are running checks.

How was this tested?

Automated tests updated/added.

Click here to see how to leverage trento playground for testing

see https://github.com/trento-project/playground

1. add a host check in the catalog

id: "TRNT01"
name: A host check
group: Trento
description: Trento agent service is enabled and running
remediation: lorem ipsum

when: env.target_type == "host"

facts:
  - name: trento_agent_service_state
    gatherer: systemd
    argument: trento-agent

values:
  - name: expected_trento_agent_service_state
    default: active

expectations:
  - name: trento_agent_service_state_active
    expect: facts.trento_agent_service_state == values.expected_trento_agent_service_state
    failure_message: Trento agent service was expected to be active (enabled and running) but returned value is '${facts.trento_agent_service_state}'

2. configure how fact gathering should behave for the check in fake_facts.yaml

targets:
  # nodes on cluster hana_cluster_1 7965f822-0254-5858-abca-f6e8b4c27714
  target1: 0a055c90-4cb6-54ce-ac9c-ae3fedaf40d4
  target2: 13e8c25c-3180-5a9a-95c8-51ec38e50cfc

  # nodes on cluster hana_cluster_2 fa0d74a3-9240-5d9e-99fa-61c4137acf81
  target3: 99cf8a3a-48d6-57a4-b302-6e4482227ab6
  target4: e0c182db-32ff-55c6-a9eb-2b82dd21bc8b

  # nodes on cluster hana_cluster_3 469e7be5-4e20-5007-b044-c6f540a87493
  target5: 9cd46919-5f19-59aa-993e-cf3736c71053
  target6: b767b3e9-e802-587e-a442-541d093b86b9

  # vmdrbddev01
  target7: 240f96b1-8d26-53b7-9e99-ffb0f2e735bf

facts:
  # other fact config

  "TRNT01":
    trento_agent_service_state:
      target1: active
      target2: active
      target3: active
      target4: active
      target5: active
      target6: active      
      target7: inactive

[abravosuse]

Code apart, it looks good to me.

@nelsonkopliku my approval is based on the attached clip. I've tried to leverage playground as well. I created the check yaml file. I updated the fake_facts.yaml file. But then when I clicked to display the result details view I got a "sorry, the page is in another castle". I guess that when I ran "make start" the built containers did not contain the change in this PR?

[nelsonkopliku]

@abravosuse I guess I understood the issue: since the PR is still not merged, the feature is still not in the demo images being used by the playground.

Now, would you mind changing the reference of the web image in the docker-compose.yaml of playground to the pr env tag? 1809-env

services:
  trento-web:
    # image: ghcr.io/trento-project/trento-web:demo
    image: ghcr.io/trento-project/trento-web:1809-env

I labeled this PR as env which builds the image

[EDIT]: food for improvements

• we could improve the pipeline by allowing also just pr env image building, and chose whether to actually deploy an environment or not
• it would be interesting providing a way (env variable? cli tool?) to choose the image you want to use for playground 🤔

[abravosuse]

Thank worked @nelsonkopliku . Thank you!

[dottorblaster]

LGTM