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

ILAB date picker updates when no ILAB jobs found #153

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

dbutenhof
Copy link
Collaborator

@dbutenhof dbutenhof commented Jan 13, 2025

Type of change

  • Refactor
  • New feature
  • Bug fix
  • Optimization
  • Documentation Update

Description

The fetchILabJobs action wasn't updating the date picker values from the API response unless a non-empty list of jobs is returned. This means that on the initial load, if the default API date range (1 month) doesn't find any jobs, the displayed list is empty and the date range isn't updated to tell the user what we've done.

I've seen no ill effects in local testing from simply removing the length check, and now the date picker is updated correctly.

This is chained from #122 (Crucible service) -> #140 (unit test framework) -> #146 (crucible unit tests) -> #123 (ilab API) -> #155 (API unit tests) -> #158 (functional test framework) -> #124 (ilab UI) -> #153 (date picker)

Related Tickets & Documents

PANDA-710

Checklist before requesting a review

  • I have performed a self-review of my code.
  • If it is a core feature, I have added thorough tests.

Testing

Tested with standard ocpperf.toml on a local server deployment. This change only affects the new ILAB component tab.

@dbutenhof dbutenhof self-assigned this Jan 13, 2025
Copy link
Member

@jaredoconnell jaredoconnell left a comment

Choose a reason for hiding this comment

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

Fix approved.

dbutenhof and others added 8 commits January 28, 2025 10:55
This encapsulates substantial logic to encapsulate interpretation of the
Crucible Common Data Model OpenSearch schema for the use of CPT dashboard API
components. By itself, it does nothing.
This uses `black`, `isort` and `flake8` to check code quality, although
failure is ignored until we've cleaned it up (which has begin in
PR cloud-bulldozer#139 against the `revamp` branch).

Minimal unit testing is introduced, generating a code coverage report.
The text summary is added to the Action summary page, and the more
detailed HTML report is stored as an artifact for download.

NOTE: The GitHub Action environment is unhappy with `uvicorn` 0.15;
upgrading to the latest 0.32.x seems to work and hasn't obviously
broken anything else.
`crucible_svc.py` test coverage is now at 97%. While the remaining 3% is
worth some effort later, the law of diminishing returns will require A
significant additional effort; and since subsequent ILAB PRs will change
some of the service code anyway it's good enough for now.
Provide the `api/v1/ilab` API endpoint to allow a client to query
collected data on a Crucible CDM OpenSearch instance through the
`crucible_svc` service layer. It is backed by the Crucible layer added
in cloud-bulldozer#122, so only the final commit represents changes in this PR.
This covers 100% of the ilab.py API module using `FastAPI`'s `TestClient`.

This proved ... interesting ... as the FastAPI and Starlette versions we use
are incompatible with the underlying httpx version ... TestClient init fails
in a way that can't be worked around. (Starlette passes an unknown keyword
parameter.)

After some experimentation, I ended up "unlocking" all the API-related
packages in `project.toml` to `"*"` and letting `poetry update` resolve them,
then "re-locked" them to those versions. The resulting combination of modules
works for unit testing, and appears to work in a real `./local-compose.sh`
deployment as well.
This adds a mechanism to "can" and restore a small prototype ILAB (Crucible
CDM) Opensearch database in a pod along with the dashboard back end, front
end, and functional tests. The functional tests run entirely within the pod,
with no exposed ports and with unique container and pod names, allowing for
the possibility of simultaneous runs (e.g., a CI) on the same system.

This also has utilities for diagnosing a CDM (v7) datastore and cloning a
limited subset, along with creating an Opensearch snapshot from that data
to bootstrap the functional test pod.

Only a few functional test cases are implemented here, as demonstration. More
will be added separately.
This relies on the ilab API in cloud-bulldozer#123, which in turn builds on the crucible
service in cloud-bulldozer#122.
The `fetchILabJobs` action wasn't updating the date picker values from the API
response unless a non-empty list of jobs is returned. This means that on the
initial load, if the default API date range (1 month) doesn't find any jobs,
the displayed list is empty and the date range isn't updated to tell the user
what we've done.

I've seen no ill effects in local testing from simply removing the length
check, and now the date picker is updated correctly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants