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

Problems running the acceptance tests on more than one node in and existing organisation #678

Open
KevinJCross opened this issue May 26, 2022 · 4 comments
Labels
backlog Will be taken care of when time allows

Comments

@KevinJCross
Copy link
Contributor

If there is configured an existing oranisation and there is more than one node running, when the test beforeSuite and After
Suite enable/disable the service access in the organisation it faces race conditions and willl cause test failures.

@asalan316
Copy link
Contributor

Still need to be addressed. More Information needed.

@KevinJCross
Copy link
Contributor Author

KevinJCross commented Sep 23, 2022

ok to be accurate .... its about this bit of code in the *_suite_test.go's

var _ = AfterSuite(func() {
	if os.Getenv("SKIP_TEARDOWN") == "true" {
		fmt.Println("Skipping Teardown...")
	} else {
		workflowhelpers.AsUser(setup.AdminUserContext(), cfg.DefaultTimeoutDuration(), func() {
			if cfg.IsServiceOfferingEnabled() && cfg.ShouldEnableServiceAccess() {
				DisableServiceAccess(cfg, setup.GetOrganizationName())
			}
		})
		setup.Teardown()
	}
})

which is run in the AfterSuite which means its run for every node! ... In the case the ORG is preset, the org is not unique for the node consequently it will be turning on and off the service access randomly during testing.

It needs to be done once per service per org ...
Either:

  • each test node has its own service instance?
  • or needs some concurrency control either by using a SynchronisedBeforeSuite or some other mechanism.

@silvestre thoughts? (would be nice to enable this for single org testing environments)

@KevinJCross
Copy link
Contributor Author

@silvestre I think going down the create a new service for each node is the best idea.
Ill do a quick rework since I need to do some alterations to be able to do the --dry-run option in ginkgo.

@silvestre
Copy link
Member

@KevinJCross : Yep, per node makes most sense.

@silvestre silvestre added the backlog Will be taken care of when time allows label Sep 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backlog Will be taken care of when time allows
Projects
None yet
Development

No branches or pull requests

3 participants