juju-test plugin should provide option to leave env alone

Bug #1271745 reported by David Britton
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Juju Charm Tools
Triaged
High
Unassigned

Bug Description

The default behavior of destroying and creating environments between test runs is spot on, but for debugging, it's slow. Please provide an option to leave the environment alone both for quick setup, and for examining the environment after the failure.

Marco Ceppi (marcoceppi)
Changed in charm-tools:
assignee: nobody → Marco Ceppi (marcoceppi)
importance: Undecided → High
status: New → Confirmed
Sean Feole (sfeole)
tags: added: hs-arm64
Revision history for this message
Marco Ceppi (marcoceppi) wrote :

There's already a flag to do this, --set-e which will break the test immediately after a test fails but prior to destroying the environment.

Changed in charm-tools:
status: Confirmed → Incomplete
Revision history for this message
Marco Ceppi (marcoceppi) wrote :

If this isn't working for you, or you need additional details, please let me know!

Revision history for this message
David Britton (dpb) wrote :

I don't believe --set-e will use an existing environment, will it?

Revision history for this message
Marco Ceppi (marcoceppi) wrote :

Sorry, no, that won't persist a bootstrap between runs, but it will stop break the test run if a test fails.

As for the don't tear down and bootstrap over and over again, there's a few different models for this and people from both camps asking. One is where a bootstrap is provided once and every test uses that. The other is like the first, only the test runner force destroys all machines in the deployment after each test (saving time for each bootstrap). I'm uncertain how requiring postmortem inspection of a failed test is not satisfied by --set-e and how having a common bootstrap addresses that

Revision history for this message
David Britton (dpb) wrote :

Also, --set-e doesn't allow inspection of the environment if things work.

In short, I'm trying to speed up the development cycle. As it is right now, I don't run juju-test, but run the test script directly, which has drawbacks (namely it's not the same test flow exactly).

Revision history for this message
Sean Feole (sfeole) wrote :

This is also a rather high priority bug with the hyperscale team. Like David, we would also like to utilize juju test. But on a manual provider ( LP #1284743) .

I see pros and cons to each of your examples in Comment #4. But if I had to choose one I would say the latter is fine with us.

"The other is like the first, only the test runner force destroys all machines in the deployment after each test (saving time for each bootstrap). "

Raghuram Kota (rkota)
Changed in charm-tools:
status: Incomplete → Confirmed
Marco Ceppi (marcoceppi)
Changed in charm-tools:
status: Confirmed → Triaged
assignee: Marco Ceppi (marcoceppi) → nobody
milestone: none → 1.7.0
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.