Create split gpg tests #1368

marmarek · Nov 1, 2015

standalone split gpg tests
split gpg + mutt tests
split gpg + thunderbird

@woju take a look at the last commit here. There a python script which is called in the VM. Since tests are started from dom0, I've stored it inside a string variable in test case and send it to the VM just before execution - to avoid dealing with dom0-vm version synchronization.
While IMHO sending the script from dom0 just before execution is fine, storing it as giant string block is quite ugly. Any better idea?

marmarek · Feb 29, 2016

@woju take a look at the last commit here. There a python script which is called in the VM. Since tests are started from dom0, I've stored it inside a string variable in test case and send it to the VM just before execution - to avoid dealing with dom0-vm version synchronization.
While IMHO sending the script from dom0 just before execution is fine, storing it as giant string block is quite ugly. Any better idea?

On Sun, Feb 28, 2016 at 05:49:39PM -0800, Marek Marczykowski-Górecki wrote:

@woju take a look at the last commit here. There a python script which
is called in the VM. Since tests are started from dom0, I've stored it
inside a string variable in test case and send it to the VM just
before execution - to avoid dealing with dom0-vm version
synchronization.

While IMHO sending the script from dom0 just before execution is fine,
storing it as giant string block is quite ugly. Any better idea?

I would prefer the tests for the Qubes applications (not core,
gui-protocol, etc.) to not be part of core tests suite. Could they be
part of their respective packages and only called from dom0 via qvm-run
or some custom qrexec? I can write a multiplexer for such qrexec, so the
"vm" tests suite would be seen as one qrexec call, irrespective of which
ones are actually installed?

woju · Feb 29, 2016

On Sun, Feb 28, 2016 at 05:49:39PM -0800, Marek Marczykowski-Górecki wrote:

@woju take a look at the last commit here. There a python script which
is called in the VM. Since tests are started from dom0, I've stored it
inside a string variable in test case and send it to the VM just
before execution - to avoid dealing with dom0-vm version
synchronization.

While IMHO sending the script from dom0 just before execution is fine,
storing it as giant string block is quite ugly. Any better idea?

I would prefer the tests for the Qubes applications (not core,
gui-protocol, etc.) to not be part of core tests suite. Could they be
part of their respective packages and only called from dom0 via qvm-run
or some custom qrexec? I can write a multiplexer for such qrexec, so the
"vm" tests suite would be seen as one qrexec call, irrespective of which
ones are actually installed?

On Mon, Feb 29, 2016 at 06:58:36AM -0800, Wojtek Porczyk wrote:

I would prefer the tests for the Qubes applications (not core,
gui-protocol, etc.) to not be part of core tests suite. Could they be
part of their respective packages and only called from dom0 via qvm-run
or some custom qrexec? I can write a multiplexer for such qrexec, so the
"vm" tests suite would be seen as one qrexec call, irrespective of which
ones are actually installed?

There are few issues with this approach (applied directly):

You need to create VMs for the test - in this case two of them
(backend, frontend), and allow qubes.Gpg service calls. This isn't
possible from within VM of course. And as you can see, "one generic VM
to run any test there" isn't enough. You need some test-specific code in
dom0.
If all the Qubes applications tests will be running as a single "vm"
test, it would be harder to get meaningful result report. Especially if
one want to parse it automatically (which I'm considering already - to
have a nice table which test fails in which template).
If calling such tests will be a separate test runner call, it would
be harder to launch all the tests.

Anyway I agree that it would be better to have those tests outside of core
tests suite (at least in terms of repositories and packaging). Maybe
there should be dedicated directory ("python package") for such tests,
like "qubes.tests.app" (this one would be in "qubes.tests.app.split_gpg").
Then it can be stored in qubes-app-linux-split-gpg repository, packaged
as a separate rpm. I think the only thing preventing this approach now,
is that tests/init.py explicitly list all test packages (static
list). Maybe such tests should be held outside "qubes" package and
loaded using some other mechanism? Something about that "egg-info"
you've shown me recently? Something else?

I'm not sure about VM part of the test in such case.
It will be simple enough to store it as a separate file in dom0
(somewhere in /usr/share/...) and transfer to VM as it's done
currently. Or package in VM part of the application (some subpackage
probably). The later one is cleaner (and also take care of
dependencies), but it's harder to maintain test machine - when you add
new test (just that), you need to update both dom0 and templates. This
makes deploying new tests more time consuming (start template, update,
stop template). But maybe still worth to do it, to have cleaner code...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · Feb 29, 2016

On Mon, Feb 29, 2016 at 06:58:36AM -0800, Wojtek Porczyk wrote:

I would prefer the tests for the Qubes applications (not core,
gui-protocol, etc.) to not be part of core tests suite. Could they be
part of their respective packages and only called from dom0 via qvm-run
or some custom qrexec? I can write a multiplexer for such qrexec, so the
"vm" tests suite would be seen as one qrexec call, irrespective of which
ones are actually installed?

There are few issues with this approach (applied directly):

You need to create VMs for the test - in this case two of them
(backend, frontend), and allow qubes.Gpg service calls. This isn't
possible from within VM of course. And as you can see, "one generic VM
to run any test there" isn't enough. You need some test-specific code in
dom0.
If all the Qubes applications tests will be running as a single "vm"
test, it would be harder to get meaningful result report. Especially if
one want to parse it automatically (which I'm considering already - to
have a nice table which test fails in which template).
If calling such tests will be a separate test runner call, it would
be harder to launch all the tests.

Anyway I agree that it would be better to have those tests outside of core
tests suite (at least in terms of repositories and packaging). Maybe
there should be dedicated directory ("python package") for such tests,
like "qubes.tests.app" (this one would be in "qubes.tests.app.split_gpg").
Then it can be stored in qubes-app-linux-split-gpg repository, packaged
as a separate rpm. I think the only thing preventing this approach now,
is that tests/init.py explicitly list all test packages (static
list). Maybe such tests should be held outside "qubes" package and
loaded using some other mechanism? Something about that "egg-info"
you've shown me recently? Something else?

I'm not sure about VM part of the test in such case.
It will be simple enough to store it as a separate file in dom0
(somewhere in /usr/share/...) and transfer to VM as it's done
currently. Or package in VM part of the application (some subpackage
probably). The later one is cleaner (and also take care of
dependencies), but it's harder to maintain test machine - when you add
new test (just that), you need to update both dom0 and templates. This
makes deploying new tests more time consuming (start template, update,
stop template). But maybe still worth to do it, to have cleaner code...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

On Mon, Feb 29, 2016 at 12:27:33PM -0800, Marek Marczykowski-Górecki wrote:

On Mon, Feb 29, 2016 at 06:58:36AM -0800, Wojtek Porczyk wrote:

I would prefer the tests for the Qubes applications (not core,
gui-protocol, etc.) to not be part of core tests suite. Could they be
part of their respective packages and only called from dom0 via qvm-run
or some custom qrexec? I can write a multiplexer for such qrexec, so the
"vm" tests suite would be seen as one qrexec call, irrespective of which
ones are actually installed?

There are few issues with this approach (applied directly):

You need to create VMs for the test - in this case two of them
(backend, frontend), and allow qubes.Gpg service calls. This isn't
possible from within VM of course. And as you can see, "one generic VM
to run any test there" isn't enough. You need some test-specific code in
dom0.

You're right. If we only had management API... Anyway, we won't have
that before implementing those tests.

If all the Qubes applications tests will be running as a single "vm"
test, it would be harder to get meaningful result report. Especially if
one want to parse it automatically (which I'm considering already - to
have a nice table which test fails in which template).

If calling such tests will be a separate test runner call, it would
be harder to launch all the tests.

Anyway I agree that it would be better to have those tests outside of core
tests suite (at least in terms of repositories and packaging). Maybe
there should be dedicated directory ("python package") for such tests,
like "qubes.tests.app" (this one would be in "qubes.tests.app.split_gpg").
Then it can be stored in qubes-app-linux-split-gpg repository, packaged
as a separate rpm. I think the only thing preventing this approach now,
is that tests/init.py explicitly list all test packages (static
list). Maybe such tests should be held outside "qubes" package and
loaded using some other mechanism? Something about that "egg-info"
you've shown me recently? Something else?

I was thinking about just that, endpoint in this egg-info thingy.

I'm not sure about VM part of the test in such case.
It will be simple enough to store it as a separate file in dom0
(somewhere in /usr/share/...) and transfer to VM as it's done
currently. Or package in VM part of the application (some subpackage
probably). The later one is cleaner (and also take care of
dependencies), but it's harder to maintain test machine - when you add
new test (just that), you need to update both dom0 and templates. This
makes deploying new tests more time consuming (start template, update,
stop template). But maybe still worth to do it, to have cleaner code...

I think it's worth it. Moreover, in earlier message you wrote that
keeping test code in dom0 allows to not think about "version
synchronization". Actually, it creates burden when the app changes.

Could just those py files be distributed in the template (possibly in
some devel packages, but they aren't exceptionally big), but the code be
kept in dom0? That would neccessitate creation of some resonably stable
API, which I think is still easier.

woju · Feb 29, 2016

On Mon, Feb 29, 2016 at 12:27:33PM -0800, Marek Marczykowski-Górecki wrote:

On Mon, Feb 29, 2016 at 06:58:36AM -0800, Wojtek Porczyk wrote:

I would prefer the tests for the Qubes applications (not core,
gui-protocol, etc.) to not be part of core tests suite. Could they be
part of their respective packages and only called from dom0 via qvm-run
or some custom qrexec? I can write a multiplexer for such qrexec, so the
"vm" tests suite would be seen as one qrexec call, irrespective of which
ones are actually installed?

There are few issues with this approach (applied directly):

You need to create VMs for the test - in this case two of them
(backend, frontend), and allow qubes.Gpg service calls. This isn't
possible from within VM of course. And as you can see, "one generic VM
to run any test there" isn't enough. You need some test-specific code in
dom0.

You're right. If we only had management API... Anyway, we won't have
that before implementing those tests.

If all the Qubes applications tests will be running as a single "vm"
test, it would be harder to get meaningful result report. Especially if
one want to parse it automatically (which I'm considering already - to
have a nice table which test fails in which template).

If calling such tests will be a separate test runner call, it would
be harder to launch all the tests.

Anyway I agree that it would be better to have those tests outside of core
tests suite (at least in terms of repositories and packaging). Maybe
there should be dedicated directory ("python package") for such tests,
like "qubes.tests.app" (this one would be in "qubes.tests.app.split_gpg").
Then it can be stored in qubes-app-linux-split-gpg repository, packaged
as a separate rpm. I think the only thing preventing this approach now,
is that tests/init.py explicitly list all test packages (static
list). Maybe such tests should be held outside "qubes" package and
loaded using some other mechanism? Something about that "egg-info"
you've shown me recently? Something else?

I was thinking about just that, endpoint in this egg-info thingy.

I'm not sure about VM part of the test in such case.
It will be simple enough to store it as a separate file in dom0
(somewhere in /usr/share/...) and transfer to VM as it's done
currently. Or package in VM part of the application (some subpackage
probably). The later one is cleaner (and also take care of
dependencies), but it's harder to maintain test machine - when you add
new test (just that), you need to update both dom0 and templates. This
makes deploying new tests more time consuming (start template, update,
stop template). But maybe still worth to do it, to have cleaner code...

I think it's worth it. Moreover, in earlier message you wrote that
keeping test code in dom0 allows to not think about "version
synchronization". Actually, it creates burden when the app changes.

Could just those py files be distributed in the template (possibly in
some devel packages, but they aren't exceptionally big), but the code be
kept in dom0? That would neccessitate creation of some resonably stable
API, which I think is still easier.

On Mon, Feb 29, 2016 at 12:52:13PM -0800, Wojtek Porczyk wrote:

I was thinking about just that, endpoint in this egg-info thingy.

I think this one applies:
https://pythonhosted.org/setuptools/pkg_resources.html#locating-plugins

Or package in VM part of the application (some subpackage probably).

Could just those py files be distributed in the template (possibly in
some devel packages, but they aren't exceptionally big), but the code be
kept in dom0? That would neccessitate creation of some resonably stable
API, which I think is still easier.

Yep, some stable API for test dom0-VM communication IMO isn't a problem.
In case of some differences, it may simply throw "skip" result.

So I think for the VM part (which in fact applies mostly to Thunderbird
tests here, as direct split-gpg calls doesn't require any additional
files there) we have final solution - have it in some subpackage
installable in the VM (template), together with its dependencies
(python-dogtail).

The remaining problem is how to handle dom0 part. The one point I've
missed above is core API. core2 (R3.0, R3.1) requires slightly different
test than core3 (R4.0). This is the main reason why I've put it into
core-admin repository... The beauty of app-linux-split-gpg component
(and in fact all of app-*) is that they all works on any Qubes version,
exactly the same code (in "master" branch). Introducing plugins using
dom0 core API may break that property (no, I'd not assume the "core3"
will be the ultimate API, stable to the end). And I want to
be able to run such tests also on R3.0 and R3.1 (at least as long as
they are supported).

There are probably many solutions for this, but the best I can think of
is to have universal test there - something that will detect core API
version and act accordingly. API usage is there quite minimal (create a
VM, then a bunch of vm.run calls), so this should be quite easy.
Probably will simply require a separate setUp functions, at least to
handle core2 and core3 at the same time.
Then design the test loading API so that it detects with which core API
versions is compatible (and throw "skip" result in case of incompatible
tests - not silently skip them). This part of the "test loading API"
may be simply some obligatory core API version check at the beginning of
such external test.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · Feb 29, 2016

On Mon, Feb 29, 2016 at 12:52:13PM -0800, Wojtek Porczyk wrote:

I was thinking about just that, endpoint in this egg-info thingy.

I think this one applies:
https://pythonhosted.org/setuptools/pkg_resources.html#locating-plugins

Or package in VM part of the application (some subpackage probably).

Could just those py files be distributed in the template (possibly in
some devel packages, but they aren't exceptionally big), but the code be
kept in dom0? That would neccessitate creation of some resonably stable
API, which I think is still easier.

Yep, some stable API for test dom0-VM communication IMO isn't a problem.
In case of some differences, it may simply throw "skip" result.

So I think for the VM part (which in fact applies mostly to Thunderbird
tests here, as direct split-gpg calls doesn't require any additional
files there) we have final solution - have it in some subpackage
installable in the VM (template), together with its dependencies
(python-dogtail).

The remaining problem is how to handle dom0 part. The one point I've
missed above is core API. core2 (R3.0, R3.1) requires slightly different
test than core3 (R4.0). This is the main reason why I've put it into
core-admin repository... The beauty of app-linux-split-gpg component
(and in fact all of app-*) is that they all works on any Qubes version,
exactly the same code (in "master" branch). Introducing plugins using
dom0 core API may break that property (no, I'd not assume the "core3"
will be the ultimate API, stable to the end). And I want to
be able to run such tests also on R3.0 and R3.1 (at least as long as
they are supported).

There are probably many solutions for this, but the best I can think of
is to have universal test there - something that will detect core API
version and act accordingly. API usage is there quite minimal (create a
VM, then a bunch of vm.run calls), so this should be quite easy.
Probably will simply require a separate setUp functions, at least to
handle core2 and core3 at the same time.
Then design the test loading API so that it detects with which core API
versions is compatible (and throw "skip" result in case of incompatible
tests - not silently skip them). This part of the "test loading API"
may be simply some obligatory core API version check at the beginning of
such external test.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

On Mon, Feb 29, 2016 at 01:58:56PM -0800, Marek Marczykowski-Górecki wrote:

On Mon, Feb 29, 2016 at 12:52:13PM -0800, Wojtek Porczyk wrote:

I was thinking about just that, endpoint in this egg-info thingy.

I think this one applies:
https://pythonhosted.org/setuptools/pkg_resources.html#locating-plugins

Yes, that's the one. It is configured with entry_points keyword argument
to setup():
https://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins

Or package in VM part of the application (some subpackage probably).

Could just those py files be distributed in the template (possibly in
some devel packages, but they aren't exceptionally big), but the code be
kept in dom0? That would neccessitate creation of some resonably stable
API, which I think is still easier.

Yep, some stable API for test dom0-VM communication IMO isn't a problem.
In case of some differences, it may simply throw "skip" result.

So I think for the VM part (which in fact applies mostly to Thunderbird
tests here, as direct split-gpg calls doesn't require any additional
files there) we have final solution - have it in some subpackage
installable in the VM (template), together with its dependencies
(python-dogtail).

The remaining problem is how to handle dom0 part. The one point I've
missed above is core API. core2 (R3.0, R3.1) requires slightly different
test than core3 (R4.0). This is the main reason why I've put it into
core-admin repository... The beauty of app-linux-split-gpg component
(and in fact all of app-*) is that they all works on any Qubes version,
exactly the same code (in "master" branch). Introducing plugins using
dom0 core API may break that property

(no, I'd not assume the "core3"
will be the ultimate API, stable to the end).

I wouldn't dare to suggest that. :)

And I want to be able to run such tests also on R3.0 and R3.1 (at
least as long as they are supported).

Core2 doesn't use setuptools. It should however be able to import
plugins from other packages, however it wouldn't be able to provide its
own plugins to fit this model. That may or may not hurt.

There are probably many solutions for this, but the best I can think of
is to have universal test there - something that will detect core API
version and act accordingly. API usage is there quite minimal (create a
VM, then a bunch of vm.run calls), so this should be quite easy.
Probably will simply require a separate setUp functions, at least to
handle core2 and core3 at the same time.
Then design the test loading API so that it detects with which core API
versions is compatible (and throw "skip" result in case of incompatible
tests - not silently skip them). This part of the "test loading API"
may be simply some obligatory core API version check at the beginning of
such external test.

Python's unittest provides loading protocol:
https://docs.python.org/2.7/library/unittest.html#load-tests-protocol.
There should be one proxy module, which instead of loading its own
testcases, would import testcases from the plugins. If we could
constrain the scope of this mechanism, we could make some simple API for
those testcases.

For example: lets suppose that this thing is intended only for testing
qrexec apps which need two vms, one for client and one for server. The
loader would take the class provided by plugin and mix it with its own,
core-dependent mixin, which would provide the test_ methods with
self.vm_server and self.vm_client. Then those tests would invoke .run()
on those vms (the API to vm objects didn't change much). At any time the
test case may invoke self.skip(), for whatever reason, but often in
idioms like

try:
vm.some_core_dependent_function(or_, core, dependent, params)
except (AttributeError, TypeError):
self.skip('core API mismatch')

There should be also some provision for setting up qrexec policy,
possibly through that mixin, like self.qrexec_policy(rpcname), which
would put an allow rule from client to server.

Would that be enough?

woju · Feb 29, 2016

On Mon, Feb 29, 2016 at 01:58:56PM -0800, Marek Marczykowski-Górecki wrote:

On Mon, Feb 29, 2016 at 12:52:13PM -0800, Wojtek Porczyk wrote:

I was thinking about just that, endpoint in this egg-info thingy.

I think this one applies:
https://pythonhosted.org/setuptools/pkg_resources.html#locating-plugins

Yes, that's the one. It is configured with entry_points keyword argument
to setup():
https://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins

Or package in VM part of the application (some subpackage probably).

Could just those py files be distributed in the template (possibly in
some devel packages, but they aren't exceptionally big), but the code be
kept in dom0? That would neccessitate creation of some resonably stable
API, which I think is still easier.

Yep, some stable API for test dom0-VM communication IMO isn't a problem.
In case of some differences, it may simply throw "skip" result.

So I think for the VM part (which in fact applies mostly to Thunderbird
tests here, as direct split-gpg calls doesn't require any additional
files there) we have final solution - have it in some subpackage
installable in the VM (template), together with its dependencies
(python-dogtail).

The remaining problem is how to handle dom0 part. The one point I've
missed above is core API. core2 (R3.0, R3.1) requires slightly different
test than core3 (R4.0). This is the main reason why I've put it into
core-admin repository... The beauty of app-linux-split-gpg component
(and in fact all of app-*) is that they all works on any Qubes version,
exactly the same code (in "master" branch). Introducing plugins using
dom0 core API may break that property

(no, I'd not assume the "core3"
will be the ultimate API, stable to the end).

I wouldn't dare to suggest that. :)

And I want to be able to run such tests also on R3.0 and R3.1 (at
least as long as they are supported).

Core2 doesn't use setuptools. It should however be able to import
plugins from other packages, however it wouldn't be able to provide its
own plugins to fit this model. That may or may not hurt.

There are probably many solutions for this, but the best I can think of
is to have universal test there - something that will detect core API
version and act accordingly. API usage is there quite minimal (create a
VM, then a bunch of vm.run calls), so this should be quite easy.
Probably will simply require a separate setUp functions, at least to
handle core2 and core3 at the same time.
Then design the test loading API so that it detects with which core API
versions is compatible (and throw "skip" result in case of incompatible
tests - not silently skip them). This part of the "test loading API"
may be simply some obligatory core API version check at the beginning of
such external test.

Python's unittest provides loading protocol:
https://docs.python.org/2.7/library/unittest.html#load-tests-protocol.
There should be one proxy module, which instead of loading its own
testcases, would import testcases from the plugins. If we could
constrain the scope of this mechanism, we could make some simple API for
those testcases.

For example: lets suppose that this thing is intended only for testing
qrexec apps which need two vms, one for client and one for server. The
loader would take the class provided by plugin and mix it with its own,
core-dependent mixin, which would provide the test_ methods with
self.vm_server and self.vm_client. Then those tests would invoke .run()
on those vms (the API to vm objects didn't change much). At any time the
test case may invoke self.skip(), for whatever reason, but often in
idioms like

try:
vm.some_core_dependent_function(or_, core, dependent, params)
except (AttributeError, TypeError):
self.skip('core API mismatch')

There should be also some provision for setting up qrexec policy,
possibly through that mixin, like self.qrexec_policy(rpcname), which
would put an allow rule from client to server.

Would that be enough?

On Mon, Feb 29, 2016 at 02:25:13PM -0800, Wojtek Porczyk wrote:

On Mon, Feb 29, 2016 at 01:58:56PM -0800, Marek Marczykowski-Górecki wrote:

On Mon, Feb 29, 2016 at 12:52:13PM -0800, Wojtek Porczyk wrote:

I was thinking about just that, endpoint in this egg-info thingy.

I think this one applies:
https://pythonhosted.org/setuptools/pkg_resources.html#locating-plugins

Yes, that's the one. It is configured with entry_points keyword argument
to setup():
https://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins

Looks good.

Python's unittest provides loading protocol:
https://docs.python.org/2.7/library/unittest.html#load-tests-protocol.
There should be one proxy module, which instead of loading its own
testcases, would import testcases from the plugins.

Yes.

Would that be enough?

Something like this, yes. I don't know if "two VMs model" is enough for
such tests (sometimes it may be necessary to setup network in some
particular way, for example). But I think, in worst case it can be
solved using try/except like you posted.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · Feb 29, 2016

On Mon, Feb 29, 2016 at 02:25:13PM -0800, Wojtek Porczyk wrote:

On Mon, Feb 29, 2016 at 01:58:56PM -0800, Marek Marczykowski-Górecki wrote:

On Mon, Feb 29, 2016 at 12:52:13PM -0800, Wojtek Porczyk wrote:

I was thinking about just that, endpoint in this egg-info thingy.

I think this one applies:
https://pythonhosted.org/setuptools/pkg_resources.html#locating-plugins

Yes, that's the one. It is configured with entry_points keyword argument
to setup():
https://pythonhosted.org/setuptools/setuptools.html#dynamic-discovery-of-services-and-plugins

Looks good.

Python's unittest provides loading protocol:
https://docs.python.org/2.7/library/unittest.html#load-tests-protocol.
There should be one proxy module, which instead of loading its own
testcases, would import testcases from the plugins.

Yes.

Would that be enough?

Something like this, yes. I don't know if "two VMs model" is enough for
such tests (sometimes it may be necessary to setup network in some
particular way, for example). But I think, in worst case it can be
solved using try/except like you posted.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Automated announcement from builder-github

The package qubes-gpg-split-2.0.19-1.fc21 has been pushed to the r3.1 testing repository for the Fedora fc21 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

QubesOS/qubes-issues

Join GitHub today

Create split gpg tests #1368

Comments

marmarek commented Nov 1, 2015

marmarek added enhancement C: tests labels Nov 2, 2015

marmarek added this to the Release 3.1 milestone Nov 2, 2015

marmarek modified the milestones: Release 3.1, Release 3.1 updates Feb 8, 2016

marmarek added a commit to marmarek/old-qubes-core-admin that referenced this issue Feb 29, 2016

marmarek added a commit to marmarek/old-qubes-core-admin that referenced this issue Feb 29, 2016

This comment has been minimized.

marmarek commented Feb 29, 2016

This comment has been minimized.

woju commented Feb 29, 2016

marmarek referenced this issue Feb 29, 2016

This comment has been minimized.

marmarek commented Feb 29, 2016

This comment has been minimized.

woju commented Feb 29, 2016

This comment has been minimized.

marmarek commented Feb 29, 2016

This comment has been minimized.

woju commented Feb 29, 2016

This comment has been minimized.

marmarek commented Feb 29, 2016

marmarek referenced this issue Mar 2, 2016

marmarek closed this in marmarek/qubes-app-linux-split-gpg@a72c81e Mar 24, 2016

marmarek added a commit to marmarek/qubes-app-linux-split-gpg that referenced this issue Mar 24, 2016

marmarek added a commit to marmarek/qubes-app-linux-split-gpg that referenced this issue Mar 24, 2016

marmarek added a commit to marmarek/qubes-app-linux-split-gpg that referenced this issue Mar 24, 2016

This comment has been minimized.

marmarek commented Mar 24, 2016

marmarek added the r3.1-fc21-cur-test label Mar 24, 2016

This comment has been minimized.

marmarek commented Mar 24, 2016

marmarek added the r3.1-fc22-cur-test label Mar 24, 2016

This comment has been minimized.

marmarek commented Mar 24, 2016

marmarek added the r3.1-fc23-cur-test label Mar 24, 2016

This comment has been minimized.

marmarek commented Mar 24, 2016

marmarek added the r3.1-dom0-cur-test label Mar 24, 2016

This comment has been minimized.

marmarek commented Mar 24, 2016

marmarek added the r3.1-jessie-cur-test label Mar 24, 2016

This comment has been minimized.

marmarek commented Mar 24, 2016

marmarek added the r3.1-stretch-cur-test label Mar 24, 2016

This comment has been minimized.

marmarek commented Mar 24, 2016

marmarek added the r3.1-wheezy-cur-test label Mar 24, 2016

This comment has been minimized.

marmarek commented Apr 19, 2016

marmarek added r3.1-fc21-stable and removed r3.1-fc21-cur-test labels Apr 19, 2016

This comment has been minimized.

marmarek commented Apr 19, 2016

marmarek added r3.1-fc22-stable and removed r3.1-fc22-cur-test labels Apr 19, 2016

This comment has been minimized.

marmarek commented Apr 19, 2016

marmarek added r3.1-fc23-stable and removed r3.1-fc23-cur-test labels Apr 19, 2016

This comment has been minimized.

marmarek commented Apr 19, 2016

marmarek added r3.1-dom0-stable and removed r3.1-dom0-cur-test labels Apr 19, 2016

This comment has been minimized.

marmarek commented Apr 19, 2016

marmarek added r3.1-jessie-stable and removed r3.1-jessie-cur-test labels Apr 19, 2016

This comment has been minimized.

marmarek commented Apr 19, 2016

marmarek added r3.1-stretch-stable and removed r3.1-stretch-cur-test labels Apr 19, 2016

This comment has been minimized.

marmarek commented Apr 19, 2016

marmarek added r3.1-wheezy-stable and removed r3.1-wheezy-cur-test labels Apr 19, 2016

This comment has been minimized.

marmarek commented May 1, 2016

marmarek added the r3.0-jessie-testing label May 1, 2016

This comment has been minimized.

marmarek commented May 1, 2016

marmarek added the r3.0-wheezy-testing label May 1, 2016

This comment has been minimized.

marmarek commented May 2, 2016

marmarek closed this in `marmarek/qubes-app-linux-split-gpg@a72c81e` Mar 24, 2016