Azure and GCP metadata decoration: integration tests#1334
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1334 +/- ##
==========================================
+ Coverage 43.56% 43.62% +0.05%
==========================================
Files 307 307
Lines 32888 32967 +79
==========================================
+ Hits 14329 14381 +52
- Misses 17641 17663 +22
- Partials 918 923 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Oh! Fun fact. Integration tests started to fail because OBI is taking the real Azure metadata from the GitHub runners instead of the mocked metadata providers. |
…nstrumentation into azure-metadata
|
Looks like the new integration test is failing ... |
|
@grcevski concretely the Azure test, which works locally but in the GitHub runner, which works in Azure, it contacts to the real Azure metadata endpoint instead of the mocked endpoint. Unlike the other OTEL resource detectors, the Azure detector doesn't seem to allow overriding the Azure endpoint. I need to have a look at the logs and see if I can configure better the Docker network. I have had to implement logging report in the new Go-based |
|
It seems that with the latest fixes to the dockerPool utility, all tests now passed. Re-running them again to discard any "lucky shot" |
It also improves the AWS EC2 tests by removing the need of mocking the
AWS_EC2_METADATA_SERVICE_ENDPOINTvariable. Now the fake IMDS is reachable at the standard169.254.169.254IP.It also uses the low-level docker client to improve some aspects of
docker_util_test:obinetwork alias to OBI so the Prometheus scraping work. Thedockerutilhigh-level API required that the network was created shortly after the OBI container was created. This caused that sometimes it retrieved for metadata before the network was ready, causing the tests to fail.