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.

Sign up for GitHub

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

Jump to bottom

Add support for --no-destroy-on-error in up() #129

Closed
wants to merge 2 commits into from
Closed

Add support for --no-destroy-on-error in up() #129

wants to merge 2 commits into from

Conversation

eighthave
Copy link
Contributor

@eighthave eighthave commented Jul 12, 2022 •
edited by ssbarnea
Loading

Fixes: #122

@eighthave eighthave mentioned this pull request Jul 12, 2022
Open
@eighthave eighthave force-pushed the no-destroy-on-error branch from c4f6589 to ac08da2 Compare July 12, 2022 23:23
konstruktoid
konstruktoid requested changes Jul 13, 2022
View reviewed changes
Copy link
Collaborator

@konstruktoid konstruktoid left a comment

Choose a reason for hiding this comment

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

Please add a test as well.

@ssbarnea ssbarnea changed the title support --no-destroy-on-error in up(), closes #122 Add support for --no-destroy-on-error in up() Jul 13, 2022
@eighthave eighthave force-pushed the no-destroy-on-error branch from ac08da2 to fe28810 Compare July 14, 2022 00:42
@eighthave
Copy link
Contributor Author

@konstruktoid I don't really understand how the test suite works, but I made an attempt.

apatard
apatard reviewed Aug 23, 2022
View reviewed changes
tests/test_vagrant.py Outdated Show resolved Hide resolved
@eighthave eighthave force-pushed the no-destroy-on-error branch from fe28810 to 9e2c80d Compare August 24, 2022 12:12
@eighthave
Copy link
Contributor Author

This works on Debian with libvirt, because vagrant up destroys the VM on error. With VirtualBox, Vagrant does not seem to destroy it when there is an error in the provision script. So I don't know how to include that info in the test suite.

@apatard
Copy link
Collaborator

apatard commented Aug 24, 2022

This works on Debian with libvirt, because vagrant up destroys the VM on error. With VirtualBox, Vagrant does not seem to destroy it when there is an error in the provision script. So I don't know how to include that info in the test suite.

oh... hashicorp/vagrant#11692 (comment)
Indeed, this will make things more complicated to test.

@eighthave eighthave force-pushed the no-destroy-on-error branch from 9e2c80d to 9404dcb Compare October 13, 2022 20:50
@eighthave
Copy link
Contributor Author

Any feedback on how to test this? Is the test still required? This is a simple change to support troubleshooting.

@apatard
Copy link
Collaborator

apatard commented Oct 17, 2022

@eighthave Given what I said in my comment, I'm not convinced that it can be tested at this moment since the CI is testing only vagrant+vbox. The solution would be to run the test only if testing against libvirt but I'm not sure it's easy and I don't know if other devs except me are testing with vagrant-libvirt.

tbh, I was hoping to get some feedback from others. @konstruktoid ? @ssbarnea ? Should the test be adapted to run only on vagrant-libvirt or any idea on how to test this or the test should be removed ?

@konstruktoid
Copy link
Collaborator

I'm so sorry @eighthave, but I've completely missed the updates on this PR.
If the test is easily adapted to run only on vagrant-libvirt I'm all for it, otherwise I'd say we remove the test and push the issue to our future selfs if there's issues later on.

@eighthave
Copy link
Contributor Author

FWIW I'm using mostly vagrant-libvirt, in testing and production. I don't know the test harness here at all, I'm happy to add something to make it libvirt only, but I don't know what that is.

@apatard
Copy link
Collaborator

apatard commented Oct 18, 2022

FWIW I'm using mostly vagrant-libvirt, in testing and production. I don't know the test harness here at all, I'm happy to add something to make it libvirt only, but I don't know what that is.

The test suite currently relies on the TEST_PROVIDER variable to know which provider is used so the idea would be to mark the test failure is fine on providers not libvirt with xfail not tested:

@pytest.mark.xfail(TEST_PROVIDER != "libvirt", reason="libvirt specific behaviour")

Skipping the test may also be an option but I guess that xfail would allow to keep the same value of PYTEST_REQPASS for all providers

@ssbarnea
Copy link
Member

ssbarnea commented Dec 8, 2022

@eighthave Any chance to rebase and fix this PR, so we can merge it? I think it would be ok to skip the test when the backend is not the ones for which it was designed.

@ssbarnea
Copy link
Member

ssbarnea commented Jan 7, 2023

I am closing this PR because it was not fixed in a long period of time. Feel free to reopen if still needed.

@ssbarnea ssbarnea closed this Jan 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@apatard apatard apatard left review comments

@konstruktoid konstruktoid konstruktoid requested changes

@ssbarnea ssbarnea Awaiting requested review from ssbarnea ssbarnea is a code owner

Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

support --no-destroy-on-error for up()
4 participants
@eighthave @apatard @konstruktoid @ssbarnea