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

PB-7821: Automate the few cluster share testcases #2734

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

sgajawada-px
Copy link
Collaborator

@sgajawada-px sgajawada-px commented Aug 14, 2024

Testcases

  • Verify Cluster Unshare deletes Restore Objects from user.
  • Verify Cluster unshare when BackupSchedules are deleted.
  • Verify RestoreObjects are not deleted when unshare from Super Admin is executed.
  • Shared user can restore to shared cluster from backup created on owned cluster.

sheet: https://docs.google.com/spreadsheets/d/1YmxvyOkwUaEKdJiInNZ4C0diXEvhsfhD6n0brYlm5lI/edit?gid=1744627660#gid=1744627660

What this PR does / why we need it:
To automate the PX-backup cluster share FC testcases

Which issue(s) this PR fixes (optional)
Closes #PB-7821

Special notes for your reviewer:
https://jenkins.pwx.dev.purestorage.com/job/portworx-backup/job/system-tests/job/byoc/job/px-backup-on-demand-system-test-byoc/6321/
https://jenkins.pwx.dev.purestorage.com/job/portworx-backup/job/system-tests/job/byoc/job/px-backup-on-demand-system-test-byoc/6324/

TestCase: Verify RestoreObjects are not deleted when unshare from Super Admin is executed
Is failed as we have not done the implementation at px-backup

[2024-08-13T18:37:15.371Z] Summarizing 1 Failure:
[2024-08-13T18:37:15.372Z] [FAIL] {ClusterShare} [It] VerifyRestoreObjectsAreNotDeletedCreatedBySuperAdmin [ClusterUnShare]
[2024-08-13T18:37:15.372Z] /go/src/github.com/portworx/torpedo/pkg/log/log.go:333
[2024-08-13T18:37:15.372Z] Ran 4 of 135 Specs in 1698.978 seconds
[2024-08-13T18:37:15.372Z] FAIL! -- 3 Passed | 1 Failed | 0 Pending | 131 Skipped
[2024-08-13T18:37:15.372Z] --- FAIL: TestBasic (1700.14s)
[2024-08-13T18:37:15.372Z] FAIL

@vsundarraj-px
Copy link
Contributor

#2729 is doing exactly same. Is this PR needed ?

// This testcase verifies whether the restores created/owned by the user were deleted during the cluster un-share.
It("VerifyRestoreObjectsAreDeletedCreatedByNonSuperAdmin", func() {
//TODO: Need to update the testrail ID
StartPxBackupTorpedoTest("VerifyRestoreObjectsAreDeletedCreatedByNonSuperAdmin", "VerifyRestoreObjectsAreDeletedCreatedByNonSuperAdmin during the cluster unshare", nil, 0, Sgajawada, Q2FY25)
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, please do not add any automation test without importing it into testrail. Testrail ID is mandatory


})
// This testcase verifies whether the restores created/owned by the user with super-admin role were not deleted during the cluster un-share.
It("VerifyRestoreObjectsAreNotDeletedCreatedBySuperAdmin", func() {
Copy link
Member

Choose a reason for hiding this comment

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

@mkoppal-px can we go ahead with multiple it's or should we break down the code where we can have one it per describe?

Copy link
Contributor

Choose a reason for hiding this comment

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

As long as the aetos dashboard shows the correct data, we are good.

_, err = Inst().Backup.InspectRestore(ctx, restoreInspectRequest)
log.FailOnError(err, "inspect restore %s", restoreName)
})

Copy link
Member

@kshithijiyer-px kshithijiyer-px Aug 14, 2024

Choose a reason for hiding this comment

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

Ideally you would want to move cleanup in JustAfterEach

@sgajawada-px
Copy link
Collaborator Author

#2729 is doing exactly same. Is this PR needed ?

@ak-px PR includes the helper functions only. Here i have included testcase also.
Once that PR is merged i can use the share and un-share utils from it

return err
}

// ShareCluster provides access to the mentioned groups or/add users
Copy link
Collaborator

Choose a reason for hiding this comment

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

comment should be updated according to unshare functionality

})

})
// This testcase verifies whether the restores created/owned by the user with super-admin role were not deleted during the cluster un-share.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we combine the above test case and this one, both looks similar apart from in the above test case we want to verify restores are deleted in case of normal user and in this we want to verify restores are not deleted in case of super admin. We can have these as two separate steps.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

As discussed with @vsundarraj-px he mentioned it is better to maintain the isolation.

restoreUID string
)

Step("Get login context for the test users", func() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we move this to beforeEach as I see we are repeating it.

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 the Step is same but here we were fetching the context after adding the role.
Example:
VerifyRestoreObjectsAreDeletedCreatedByNonSuperAdmin - Uses infra admin role
VerifyRestoreObjectsAreNotDeletedCreatedBySuperAdmin - Uses the super admin role
Fetching the context should be after assigning the user role. So it cant be part of JustBeforeEach

}
})

Step("Create a cluster object with User1 and Share with User2", func() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same here, we are repeating it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It can't be part of JustBeforeEach because
VerifyRestoreCreateBySharedClusterUser is sharing a destination cluster and all the testcases were sharing the source cluster

dash.VerifyFatal(err, nil, fmt.Sprintf("Verifying share of source [%s] cluster with %s user using %s ctx", SourceClusterName, testUsers[2].name, testUsers[1].name))
})

Step("Create backup location and cloud setting with User2", func() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This one too we are repeating same lines of code

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done


})
// This testcase verifies the restore creation on the shared cluster by the shared user.
It("VerifyRestoreCreateBySharedClusterUser", func() {
Copy link
Collaborator

@dbinnal-px dbinnal-px Aug 16, 2024

Choose a reason for hiding this comment

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

Can we verify this case also as part of the first testcase you have written? Looks like it is just verifying restore creation which is part of first testcase

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

As discussed with @vsundarraj-px he mentioned it is better to maintain the isolation.

backupDriver := Inst().Backup
userIDs := make([]string, 0)

clusterUid, err := backupDriver.GetClusterUID(ctx, BackupOrgID, clusterName)
Copy link
Contributor

Choose a reason for hiding this comment

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

@sgajawada-px I'm passing clusterUid as an input parameter for both methods in my PR. Fetching clusterUid may cause issues if the context is admin and the admin has multiple clusters from users with the same name. If you are planning to rebase with my branch, it's better to pass clusterUid at the test case level.

Copy link
Contributor

@mkoppal-px mkoppal-px left a comment

Choose a reason for hiding this comment

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

Few things to note here:

  • Please submit one test case per PR. It alway better to have multiple small PRs rather than a one big PR. Easier to review and maintain.
  • Create sub directory under tests/backup called backup-functional and move the _test.go files there

@vsundarraj-px
Copy link
Contributor

@mkoppal-px Not sure we can combine one Test case with one PR. We have created FC tasks based on object operation. For instance restore related test cases will be combined with 1 task.
Similarly, Backup and backup schedule related test cases will have one task again and each task will associate with 1 pr.

@mkoppal-px
Copy link
Contributor

@mkoppal-px Not sure we can combine one Test case with one PR. We have created FC tasks based on object operation. For instance restore related test cases will be combined with 1 task. Similarly, Backup and backup schedule related test cases will have one task again and each task will associate with 1 pr.

We usually create one task per test case. It is easier to track and review.

- Verify Cluster Unshare deletes Restore Objects from user.
- Verify Cluster unshare when BackupSchedules are deleted.
- Verify RestoreObjects are not deleted when unshare from Super Admin is executed.
- Shared user can restore to shared cluster from backup created on owned cluster.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants