spawn a new deis cluster (in a new namespace) for each run

Question

spawn a new deis cluster (in a new namespace) for each run

arschles opened this issue 9 years ago · comments

this one may be involved, but it would be nice to create a new deis cluster in its own namespace for each test run, and then tear it down at the end. this would eliminate a whole class of state management issues across test suite runs, and also allow us to run multiple suite concurrently on the same k8s cluster.

also note that I believe we have some outstanding issues that prevent us from running 2+ deis clusters reliably on the same k8s cluster, so those will have to be cleared before this can be possible.

Purposefully not assigned a milestone, as this is a nice to have and not critical.

Jonathan Chauncey commented 8 years ago

See #142

Matt Butcher · Answer 1 · Fri Jan 01 2016 02:11:31 GMT+0800 (China Standard Time)

Can we run on helm HEAD and see if the new template logic will make this easy? There are random functions available to templates that might give us exactly this feature.

Aaron Schlesinger · Answer 2 · Fri Jan 01 2016 03:07:13 GMT+0800 (China Standard Time)

@technosophos yea, that'd work. we can have the BeforeSuite issue the helm install with the proper template values, and then wait until all pods are up and running before continuing

Matt Boersma · Answer 3 · Fri Jan 01 2016 03:14:47 GMT+0800 (China Standard Time)

I think provisioning should remain separate from the tests themselves this time. One reason is that the e2e tests had also been envisioned as a "sanity check" on a user's newly installed cluster before it's put into service, and in that case automatically provisioning / decommissioning would interfere. Another use case that past experience shows is important was captured by the SKIP_CLEANUP env var in the "old" integration tests: provision and run the tests but leave everything intact for further forensic examination.

I don't feel that strongly about this, but I can see value to keeping provisioning and testing separate. Or at the least, allowing the helm parts of BeforeSuite/AfterSuite to be skipped if we do follow through with this proposal.

Aaron Schlesinger · Answer 4 · Fri Jan 01 2016 03:20:42 GMT+0800 (China Standard Time)

One reason is that the e2e tests had also been envisioned as a "sanity check" on a user's newly installed cluster before it's put into service, and in that case automatically provisioning / decommissioning would interfere

@mboersma excellent point. 👍

Or at the least, allowing the helm parts of BeforeSuite/AfterSuite to be skipped if we do follow through with this proposal.

I'm ok with either way. Leaning toward putting the helm install + wait for pods logic into a completely separate program because I imagine it could be reusable down the line. Also it's more unixey.

Regardless, I do think we should follow through with this proposal in the beta cycle. Would be nice to see these tests run as part of our pipeline at some point.