tail blobfuse-proxy logs at the start of blobfuse-proxy daemonset

[boddumanohar]

What type of PR is this?
tail blobfuse-proxy logs at the start of blobfuse-proxy daemonset

/kind cleanup

What this PR does / why we need it: #392

Which issue(s) this PR fixes:

Fixes #

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• tested upgrade from previous version

Special notes for your reviewer:

Release note:

none

[k8s-ci-robot]

Hi @boddumanohar. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[andyzhangx]

/ok-to-test

[andyzhangx]

that means it can only get logs in the exact time of after 10s, is there better way to get all logs after all tests completed?

[boddumanohar]

it is getting all the logs. In the above case, the sleep is to wait for the blobfuse-proxy service to come up. Although it happens much quicker than that.

[andyzhangx]

should filter out AZURE_STORAGE_ACCESS_KEY in blobfuse-proxy logging and better keep other fields in the logs:

received auth env [AZURE_STORAGE_ACCESS_KEY=xxx AZURE_STORAGE_ACCOUNT=fusecd9d3dacdfc94335852 

[boddumanohar]

@andyzhangx The .deb file present in the master is a little old. So I updated it with the latest one. Now we can observe we are not leaking secrets in the logs.

also, the current method we are using to distribute the .deb file is a little tedious. Because if someone made changes to the blobfuse-proxy then they have to build the new .deb themselves and update the links in deploy/blobfuse-proxy/blobfuse-proxy.yaml. And there is no way to guarantee its if the .deb file is legit. Instead its better if we have some automation around this.

[boddumanohar]

instead of creating a separate PR to to change: boddumanohar --> kubernetes-sigs . Can I update it right now? So that when the PR is merged, it will point to the correct file itself.

[andyzhangx]

ok

[andyzhangx]

@andyzhangx The .deb file present in the master is a little old. So I updated it with the latest one. Now we can observe we are not leaking secrets in the logs.

also, the current method we are using to distribute the .deb file is a little tedious. Because if someone made changes to the blobfuse-proxy then they have to build the new .deb themselves and update the links in deploy/blobfuse-proxy/blobfuse-proxy.yaml. And there is no way to guarantee its if the .deb file is legit. Instead its better if we have some automation around this.

@boddumanohar could add a verification script in hack/ folder, it could build deb file automatically and do md5sum check with existing one, if there is diff, then verification failed?

[boddumanohar]

@andyzhangx do you want me to propose the changes discussed above in this PR itself or a new PR?

[andyzhangx]

@andyzhangx do you want me to propose the changes discussed above in this PR itself or a new PR?

@boddumanohar new PR is ok

[andyzhangx]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx, boddumanohar

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [andyzhangx]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment