Peter Engelbert

@jonjohnsonjr Specifically, can you put together a PR for items 1 and 2 (`Accept` headers and links to image spec, etc). You have a great deal of experience with this...

@hewatson-msft Thanks for this. Eraser v1.0.0 will record metrics using opentelemetry, which will include - images discovered on cluster - results of image scans (if any) - images that were...

@sozercan yes, this is why I reopened the issue. It's been difficult to reproduce, so I'll add these logs to the issue tracking intermittent failures @vyta

The test timed out twice in a row. It may actually be related to the changes, though I don't know why.

The failure I experienced was `eraser_test.go:254: timeout waiting for images to be cleaned`. It could be that the process just needs a longer timeout. It could be that something else...

After I ran the tests, I got the following: ```bash $ kubectl logs -n eraser-system eraser-eraser-e2e-test-worker2 |jq { "level": "info", "ts": 1650037176.5409193, "logger": "eraser", "msg": "Image is not on node",...

In addition, the tests are not always removing the `imagejob` object in the teardown, which may be causing repeated failures. Once the tests fail once they tend to continue to...

I just got the failure: ``` { "level": "info", "ts": 1650043460.1393516, "logger": "eraser", "msg": "Image is not on node", "image": "sha256:2834dc507516af02784808c5f48b7cbe38b8ed5d0f4837f16e78d00deb7e7767" } { "level": "info", "ts": 1650043460.1393642, "logger": "eraser", "msg":...

I can confirm that the `wait` is insufficient. If I put a `time.Sleep` between the `wait.For`s and the eraser deployment, it seems to resolve the issue. Obviously, `time.Sleep` is not...

There are still intermittent timeouts in the CI. The problem is much better since #143, but there are still occasional instances where timeout occurs without a discernable reason.