Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests: create more tests for monitoring dashboard #1806

Conversation

justinsb
Copy link
Collaborator

  • tests: create more tests for monitoring dashboard
  • mockgcp: more fidelity for project creation
  • tests: pass a sensible default folder id in hack/record-gcp

@justinsb justinsb added this to the 1.119 milestone May 15, 2024
@justinsb justinsb force-pushed the monitoring_dashboard_more_tests branch from 2f58ae8 to a0bf4b6 Compare May 15, 2024 22:42
Copy link
Collaborator

@acpana acpana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

couple questions but overall looking good!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did we mean to regenerate this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this file should have moved, we don't have a consistent testfixture structure, so when we add our second test we have to move the first one into a subdirectory. What happened here is that git detected some of the deletions as renames - I think the final state is correct.

(FYI, git renames are a client-side construct ... and so are diffs)

if err != nil {
return nil, err
}

return lroV3ToV1(lro)
// Note: Unclear if we should wait for the operation, I _think_ no.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we not need to wait for the op to finish?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So V1 doesn't return an LRO. I think we get away with it here because V3 DeleteProject is actually synchronous. I'll expand the comment.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I decided it was easier just to wait for the operation. Then we don't have to worry about the implementation details of V3 DeleteProject

hack/record-gcp Outdated
@@ -9,6 +9,10 @@ rm -rf $(pwd)/artifactz/realgcp

RUN_TESTS=TestAllInSeries/$1

DEFAULT_PROJECT=$(gcloud config get project)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a reminder that this will fail in GH actions. It would be helpful if we "err out" or log out if any of these are empty or can use my trick to ?= and accept whatever we set in GH env.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, fair, though this script is meant for use locally.

I'll change it to default the project if not set!

It's not perfect (v3 vs v1 is tricky), but it's much closer.
This allows us to record test output even when we must create a project.
@justinsb justinsb force-pushed the monitoring_dashboard_more_tests branch from a0bf4b6 to defba09 Compare May 22, 2024 13:16
if err != nil {
return nil, err
}

return lroV3ToV1(lro)
// Note: Unclear if we should wait for the operation, I _think_ no.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I decided it was easier just to wait for the operation. Then we don't have to worry about the implementation details of V3 DeleteProject

filter: metric.type="agent.googleapis.com/nginx/connections/accepted_count"
resourceNames:
- external: "projects/other${uniqueId}"
# TODO: Switch to a ref
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bummer, although it opens a door.

Looks like logsPanel.resourceNames with a reference to a Project is broken in TF/DCL.

The good news is that because it's broken, I think we have more wiggle room in terms of whether kind should be required etc.

Sadly, the test is not very interesting because of this bug, but we'll fix that as part of going direct!

User-Agent: google-api-go-client/0.5 Terraform/ (+https://www.terraform.io) Terraform-Plugin-SDK/2.10.1 terraform-provider-google-beta/kcc/controller-manager
X-Goog-Api-Client: gl-go/1.22.3 gdcl/0.177.0

200 OK
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a pity that many server uses 200 rather than 204 on empty response.

User-Agent: google-api-go-client/0.5 Terraform/ (+https://www.terraform.io) Terraform-Plugin-SDK/2.10.1 terraform-provider-google-beta/kcc/controller-manager
X-Goog-Api-Client: gl-go/1.22.3 gdcl/0.177.0

403 Forbidden
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, didn't realize this returns 403 rather than 404.


// Wait for the operation to complete.
// If the operation is not done after timeout, an error is returned.
func (o *Operations) Wait(ctx context.Context, opName string, timeout time.Duration) (*longrunningpb.Operation, error) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mind adding a little bit more comment to suggest when and how to use the wait? Or is this to make the mock LRO be more like a real LRO? I assume mock tests should be done pretty fast.

@yuwenma
Copy link
Collaborator

yuwenma commented May 22, 2024

/lgtm
/approve

No blocker and the PR looks great! feel free to resolve comments in follow up PRs.

Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: yuwenma

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:

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

@google-oss-prow google-oss-prow bot merged commit b17e40c into GoogleCloudPlatform:master May 22, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants