Cloud Foundry Buildpack for Collector #1404
Conversation
|
Maybe outside of the scope of this PR, but is there anything we can add for CI testing? |
|
@jeffreyc-splunk In regards to adding CI testing, I don't think the actual functionality can be automated at this point. The problem is that this requires a Tanzu Application Service (TAS) instance, which currently needs to be created by specific users through a VMware dashboard. I don't believe the current usage agreement would allow for spinning up instances for testing. I'll check to make sure my understanding is correct, but that's why I hadn't implemented anything at this point. |
Maybe at a minimum, would it be possible to add a job to just create the buildpack and ensure that the |
That should be doable, I'll work on adding that. |
crobert-1
force-pushed
the
cf-buildpack-deploy
branch
from
e69e26b
to
921a4b8
Compare
|
@jeffreyc-splunk I've added a basic CI test that just makes sure the supply script runs successfully. I wanted to also make sure the buildpack is built successfully, but unfortunately that also requires a Cloud Foundry instance to be running, so it isn't feasible. I'm not very familiar with GitHub automation, so please let me know if there's anything to fix! |
crobert-1
force-pushed
the
cf-buildpack-deploy
branch
from
ad4df31
to
53bf40c
Compare
This is a deployment of the OpenTelemetry Collecter in the format of a Cloud Foundry buildpack. This buildpack supplies the Collector to the app it is used for. When the app is deployed it can run and configure the Collector as a sidecar (as described in the README). This will allow the Collector to observe the given app as well as the whole environment's metrics.
- Remove SignalFX references in favor of Splunk - Output wget errors and document wget dependency - Add example error to troubleshooting - Fix typos - Remove unecessary variables
- Use binary file rather than tar.gz to install - Use splunk distribution instead of upstream - Update variable reference in readme to match script usage - Move URL variables in README to required section for clarity
- Use Splunk distribution, not core - Use latest version (unless specified otherwise), instead of preset values - Clean up variable names - Add documentation references
- Add CI tests for buildpack. Just runs supply script and checks if it's successful. - Add Splunk to all Otel collector references - Setup patch interpreter for SignalFx Smart Agent, this makes sure signalfxreceiver will work properly.
Use absolute paths instead of relative. Also, mkdir instead of creating files, which was incorrect.
- Add smart agent variable to README - Add Splunk to OpenTelemetry references - Update OS variable information - Update dependencies in README
- Don't install smart agent patch interpreter if OS isn't supported. - Moved version checking so output messages would include OS properly.
crobert-1
force-pushed
the
cf-buildpack-deploy
branch
from
3405ebb
to
1a02784
Compare
| - `RLP_GATEWAY_ENDPOINT` - The URL of the RLP gateway that acts as the proxy for the firehose, | ||
| e.g. `https://log-stream.sys.<TAS environment name>.cf-app.com` | ||
| - `UAA_ENDPOINT` - The URL of UAA provider, | ||
| e.g. `https://uaa.sys.<TAS environment name>.cf-app.com` |
There was a problem hiding this comment.
@crobert-1 Can you update https://github.com/signalfx/splunk-otel-collector/blob/main/.github/workflows/lychee.yml#L24 to exclude *.cf-app.com?
There was a problem hiding this comment.
Will do, thanks for pointing this out!
These links are just there as an example, but invalid. The lychee workflow was failing because it expected these to be real.
This is a deployment of the OpenTelemetry Collecter in the format of a
Cloud Foundry buildpack. This buildpack supplies the Collector to the
app it is used for. When the app is deployed it can run and configure
the Collector as a sidecar (as described in the README). This will allow
the Collector to observe the given app as well as the whole environment's
metrics.