You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current nodemanager tests will spawn a --test-mode instance of the nodemanager to run the test cases against. Tests and test-mode NM run on the same machine. However, this is difficult to do correctly on platforms like Android, where we often don't have proper shell access, and/or extra caution may be needed (with respect to Popen (SeattleTestbed/utf#53), standard streams (SeattleTestbed/utf#68), C libraries (SeattleTestbed/repy_v2#98) etc.)
To run the tests against a remote NM instance, the tests would use the owner key pair for the vessels-to-test, rather than creating fresh temporary keys and setting up a local NM. Afterwards, the tests should proceed as they do now, testing NM API interactions and so on.
This raises a couple of design questions.
How do signal to the test that you want to test a remote NM? (Just leave a specially-named key pair in the test dir?)
What exact configuration does the remote vessel need? (Number of vessels, keys used; resources?)
Which tests can be run against a remote NM? (E.g., we can't access the nodemanager log in the general case.)
What additional tests do we need?
I would prefer to not duplicate all of the existing tests in a separate test module namespace. NM tests should probably default to the usual all-local method unless an educated user flips the required switch to run against a remote NM instance.
The text was updated successfully, but these errors were encountered:
The current nodemanager tests will spawn a
--test-mode
instance of the nodemanager to run the test cases against. Tests and test-mode NM run on the same machine. However, this is difficult to do correctly on platforms like Android, where we often don't have proper shell access, and/or extra caution may be needed (with respect toPopen
(SeattleTestbed/utf#53), standard streams (SeattleTestbed/utf#68), C libraries (SeattleTestbed/repy_v2#98) etc.)To run the tests against a remote NM instance, the tests would use the owner key pair for the vessels-to-test, rather than creating fresh temporary keys and setting up a local NM. Afterwards, the tests should proceed as they do now, testing NM API interactions and so on.
This raises a couple of design questions.
I would prefer to not duplicate all of the existing tests in a separate test module namespace. NM tests should probably default to the usual all-local method unless an educated user flips the required switch to run against a remote NM instance.
The text was updated successfully, but these errors were encountered: