search

Dynatrace / libbuildpack-dynatrace

Common resources used for Dynatrace integration in Cloudfoundry Buildpacks.
Apache License 2.0
1 stars 5 forks source link

Buildpack showed errors after import libbuildpack-dynatrace v1.5.0 instead of v1.4.2 #22

Closed zyisi closed 1 year ago

zyisi commented 1 year ago

Buildpack showed errors after import libbuildpack-dynatrace v1.5.0 instead of v1.4.2 (Nodejs Buildpack 1.8.0 import Dynatrace/libbuildpack-dynatrace v1.5.0 while Buildpack 1.7.69 import v1.4.2. ) 

The issue looks like calling dynatrace “updateAgentConfig” func in https://github.com/Dynatrace/libbuildpack-dynatrace/blob/v1.5.0/hook.go#L181 and this func first appears in Dynatrace 1.5.0 

Was there a significant change in this release that causes the build to fail? Or should we have any additional settings?

Here are the error messages: 11:10:26.54+0530 [STG/0] OUT DEBUG: Checking for enabled dynatrace service... 11:10:26.54+0530 [STG/0] OUT DEBUG: Found one matching service: foo-dynatrace 11:10:26.54+0530 [STG/0] OUT Dynatrace service credentials found. Setting up Dynatrace OneAgent. 11:10:26.54+0530 [STG/0] OUT Downloading 'https:///apm-service-broker-s3-new/XI7VF-BuRX2uApscZ0wwG_d02009af-1682-4506-937e-61b5614b5f5a' to '/tmp/paasInstaller.sh' 11:10:26.88+0530 [STG/0] OUT DEBUG: Making /tmp/paasInstaller.sh executable... 11:10:26.88+0530 [STG/0] OUT -----> Starting Dynatrace OneAgent installer 11:10:26.88+0530 [STG/0] OUT 05:40:26 Installing to /tmp/app 11:10:26.89+0530 [STG/0] OUT 05:40:26 Extracting... 11:10:26.98+0530 [STG/0] OUT 05:40:26 Unpacking to '/tmp/app/dynatrace/oneagent' ... 11:10:28.40+0530 [STG/0] OUT 05:40:28 Unpacking complete. 11:10:28.41+0530 [STG/0] OUT Dynatrace OneAgent installed. 11:10:28.41+0530 [STG/0] OUT -----> Setting up Dynatrace OneAgent injection... 11:10:28.41+0530 [STG/0] OUT DEBUG: Copy dynatrace-env.sh to /tmp/contents687094651/deps/0/profile.d/dynatrace-env.sh 11:10:28.41+0530 [STG/0] OUT DEBUG: Open /tmp/contents687094651/deps/0/profile.d/dynatrace-env.sh for modification... 11:10:28.41+0530 [STG/0] OUT DEBUG: Setting LD_PRELOAD... 11:10:28.41+0530 [STG/0] OUT DEBUG: Setting DT_LOGSTREAM to stdout... 11:10:28.41+0530 [STG/0] OUT DEBUG: Preparing custom properties... 11:10:28.41+0530 [STG/0] OUT DEBUG: Fetching updated OneAgent configuration from tenant... 11:10:34.41+0530 [STG/0] OUT ERROR Failed to fetch OneAgent config from API: Get "https://foo/e//v1/deployment/installer/agent/processmoduleconfig": context deadline exceeded (Client.Timeout exceeded while awaiting headers) 11:10:34.41+0530 [STG/0] OUT ERROR Error during agent config update: Get "https://foo/e//v1/deployment/installer/agent/processmoduleconfig": context deadline exceeded (Client.Timeout exceeded while awaiting headers) 11:10:34.41+0530 [STG/0] OUT ERROR After Compile: Get "https://foo/e//v1/deployment/installer/agent/processmoduleconfig": context deadline exceeded (Client.Timeout exceeded while awaiting headers) 11:10:34.56+0530 [STG/0] ERR Failed to compile droplet: Failed to run finalize script: exit status 13 11:10:34.56+0530 [STG/0] OUT Exit status 223

arthfl commented 1 year ago

@zyisi the updateAgentConfig part was added in v1.5.0, so yes there is this significant change.

Are you running this against a real Dynatrace tenant or against some fake URL? Because it will definitly fail if it's the latter.

zyisi commented 1 year ago

@arthfl Thanks for your reply. It seems the service configuration problem. I will go to double check.

arthfl commented 1 year ago

@zyisi You're welcome. I'm closing this then :-)

ajaymatters commented 1 year ago

Hi @arthfl,

I had originally raised this issue.

The URL given is only a placeholder here - we definitely use a valid api URL in our firm's settings. But even then, the HTTP request to apiurl+"/v1/deployment/installer/agent/processmoduleconfig" will result in an error because of:

  1. The network restrictions we place on the staging container
  2. The Dynatrace setup we have in our company does not allow such API requests.

This line which gets executed in our scenario causes the entire staging to fail.

Shouldn't the function handle the case of there being no configuration updates from the tenant at all, and rather revert to using the static version provided by the originally downloaded package if it fails to find/update the configuration?

arthfl commented 1 year ago

@ajaymatters Can you share some details about the network restrictions for the staging containers you have in place?

You can also find me on the CF slack under my name if you don't want to discuss this here in public or for exchanging other means of communication.

ajaymatters commented 1 year ago

Nearly all connections are restricted from the staging containers except for the internal storage solution which houses the Dynatrace installer agent and other such dependencies a buildpack would require.