fix(backend): fixes healthz response by adding json content type. Fixes #7525

[hsinhoyeh]

Description of your changes:

1. explicit content type with application/json on healthz response.
2. add healthz client api under common/client for integration test
3. add integration test for healthz endpoint

Checklist:

• The title for your pull request (PR) should follow our title convention. Learn more about the pull request title convention used in this repository.

[google-oss-prow]

Hi @hsinhoyeh. Thanks for your PR.

I'm waiting for a kubeflow 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.

[hsinhoyeh]

few thoughts for this PR:

1. I don't think we should touch [WaitForReady] (https://github.com/kubeflow/pipelines/blob/master/backend/test/test_utils.go#L39) during this PR as its primary job is to ensure the backend api is ready for test. It is better to pass the raw http.Response for better assessing its status.
2. According to previous point, so I added a test suite for Healthz, hope it will not over-tested.

[zijianjoy]

Can we check the content within healthzResp are json parsable?

[zijianjoy]

To show more about what I mean: For example: you can check the content within healthzResp contains multi_user key and value: https://github.com/kubeflow/pipelines/blob/74c7773ca40decfd0d4ed40dc93a6af591bbc190/backend/api/python_http_client/docs/ApiGetHealthzResponse.md.

[hsinhoyeh]

@zijianjoy thanks for the reply, but I think I still don't get it.
the question here is healthzResp is a well-defined structure, you can check the structure definition here

pipelines/backend/api/go_client/healthz.pb.go

Line 44 in 74c7773

type GetHealthzResponse struct {

so the field multi-user will be there.

But I think the question is: are we able to verify the field value multi-user to be true in a multi-tenancy setup. (as the multi-user field is a simple boolean field, we are unable to verify when the value is not presented.)
And still, it is hard to verify during this test (as we should be able to create a test environment w/o multiuser).

[zijianjoy]

/ok-to-test

[zijianjoy]

/lgtm
/approve

Thank you for your change! @hsinhoyeh

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: zijianjoy

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:

• backend/OWNERS [zijianjoy]

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