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.

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

Integrate Slurm with Travis CI of Launchmon #25

Open
mcfadden8 opened this issue May 11, 2016 · 1 comment
Open

Integrate Slurm with Travis CI of Launchmon #25

mcfadden8 opened this issue May 11, 2016 · 1 comment

Comments

@mcfadden8
Copy link

Just creating ticket as a way to inform others that this would be a useful feature and that I'm interested in doing it at some point.

@dongahn
Copy link
Collaborator

dongahn commented May 12, 2016

@mcfadden8:

As discussed, this will be a great contribution and represents a huge undertake on your part! I think it would be wise to break this down to multiple smaller tasks and take some baby steps along the way.

Some of the interesting early experiments would be:

  1. Add gcc+slurm in .travis.yml, and for this testing instance, see if one can install a SLURM package and run them to become the system resource manager for the Travis VM instance.
  2. Add automake's testing rig for two very basic tests (test/test.launch_1.in and test/test.attach_1.in) such as a way that make check will run them and the new testing rig can harvest TAP output. Sharness has been working great for my other project to write the tests.
  3. This also means one will have to modify these test codes and scripts such a way that success/failure can be reliably harvesedt with no apparent race condition. My experience has been setting this up for distributed/parallel environment is not trivial.

In any case, once 1 and 2 are done, let's discuss how we can make our test cases and scripts more suitable for automatic regression testing environments.

Once your effort establishes a feasibility, I can see why we will ultimately want to add testing instances for

  • gcc+orterun
  • gcc+intel_hydra
    ...

I probably won't be able to set up testing instance for CORAL Sierra as desired by Issue #17 or Blue Gene/Q. But we should try to cover as many RM environments as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants