Update agent config during init only in case of installer mode #718
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If securityContext with user/group is used on a user's pod that we inject a csi volume into, then the standalone-init will fail as it doesn't have the permissions to update the
ruxitagentproc.conf
file.This happens because the csi-driver creates/updates that file with a different user/group then what the user's pod's securityContext has which is used by the standalone-init.
How can this be tested?
Have cloud-native and inject into a sample app that has a securityContext with a user/group that is different from the one that the csi-driver is using. The sample app should just work.
For bonus-points: Have app-monitoring WITHOUT csi-driver, deploy the same sample app, check that its running, and check if the
ruxitagentproc.conf
was updated.opt/dynatrace/oneagent-paas/agent/conf/
in the injected container, if there is a_ruxitagentproc.conf
if it was updatedChecklist