fix(discovery): fix duplicate pod nodes in container discovery

[tthvo]

Welcome to Cryostat3! 👋

Before contributing, make sure you have:

• [x] Read the contributing guidelines
• [x] Linked a relevant issue which this PR resolves
• [x] Linked any other relevant issues, PR's, or documentation, if any
• [x] Resolved all conflicts, if any
• [x] Rebased your branch PR on top of the latest upstream main branch
• [x] Attached at least one of the following labels to the PR: [chore, ci, docs, feat, fix, test]
• [x] Signed all commits using a GPG signature

To recreate commits with GPG signature git fetch upstream && git rebase --force --gpg-sign upstream/main

---

Fixes: #412

Description of the change:

• Fetched (pod) discovery node from database if any when handling FOUND event.
• Fixed deletion fails when deleting pods (i.e. podman), thus causing new containers to be considered duplicate.
  • Need a label to keep track of the container ID so that we just delete by container id instead of fetching for container information. In the case of LOST event, the query will return null -> NullPointerException.
  • With this fix, deleting a pod now works fine.

Motivation for the change:

See #412

How to manually test:

podman pod create --replace --name cryostat-pod

podman run \
        --name jmxquarkus \
        --pod cryostat-pod \
        --label io.cryostat.discovery="true" \
        --label io.cryostat.jmxPort="51423" \
        --env QUARKUS_HTTP_PORT=10012 \
        --rm -d quay.io/roberttoyonaga/jmx:jmxquarkus@sha256:b067f29faa91312d20d43c55d194a2e076de7d0d094da3d43ee7d2b2b5a6f100

podman run \
        --name vertx-fib-demo-0 \
        --env HTTP_PORT=8079 \
        --env JMX_PORT=9089 \
        --env START_DELAY=60 \
        --pod cryostat-pod \
        --label io.cryostat.discovery="true" \
        --label io.cryostat.jmxHost="vertx-fib-demo-0" \
        --label io.cryostat.jmxPort="9089" \
        --rm -d quay.io/andrewazores/vertx-fib-demo:0.13.1

[tthvo]

/build_test

[github-actions[bot]]

Workflow started at 4/25/2024, 7:43:38 PM. View Actions Run.

[github-actions[bot]]

No OpenAPI schema changes detected.

[github-actions[bot]]

No GraphQL schema changes detected.

[github-actions[bot]]

CI build and push: All tests pass ✅ (JDK17) https://github.com/cryostatio/cryostat3/actions/runs/8840828545

[tthvo]

https://github.com/cryostatio/cryostat3/blob/2027869c0c4f033cf3175d0a687d181940a59ae4/src/main/java/io/cryostat/discovery/ContainerDiscovery.java#L197

I think the diff operation here should be done against persisted targets instead? Otherwise, if cryostat is restarted, it will cause all previously observed containers to be pruned. I will save that for another PR tho to keep this one minimal...

[andrewazores]

https://github.com/cryostatio/cryostat3/blob/2027869c0c4f033cf3175d0a687d181940a59ae4/src/main/java/io/cryostat/discovery/ContainerDiscovery.java#L197

I think the diff operation here should be done against persisted targets instead? Otherwise, if cryostat is restarted, it will cause all previously observed containers to be pruned. I will save that for another PR tho to keep this one minimal...

I don't think it's that big of a problem, since the correct data will end up getting restored into the database again when Cryostat does come back and query the container platform again. They'll just end up with new database IDs, which seems like a minor annoyance. If you'd like to fix that in another PR I'd be happy to review it though.

[andrewazores]

/build_test

[github-actions[bot]]

Workflow started at 4/26/2024, 11:46:03 AM. View Actions Run.

[github-actions[bot]]

No OpenAPI schema changes detected.

[github-actions[bot]]

No GraphQL schema changes detected.

[github-actions[bot]]

CI build and push: All tests pass ✅ (JDK17) https://github.com/cryostatio/cryostat3/actions/runs/8850852121

[tthvo]

https://github.com/cryostatio/cryostat3/blob/2027869c0c4f033cf3175d0a687d181940a59ae4/src/main/java/io/cryostat/discovery/ContainerDiscovery.java#L197

I think the diff operation here should be done against persisted targets instead? Otherwise, if cryostat is restarted, it will cause all previously observed containers to be pruned. I will save that for another PR tho to keep this one minimal...

I don't think it's that big of a problem, since the correct data will end up getting restored into the database again when Cryostat does come back and query the container platform again. They'll just end up with new database IDs, which seems like a minor annoyance. If you'd like to fix that in another PR I'd be happy to review it though.

Sure! And actually, from another look, I think it would instead leave stale (removed containers) targets intact and cause duplicate key violation when cryostat comes back up again. I will work a PR for that...