<div>Hey David,<br>I'd love to see the source for this, is it in svn? If you'd like, I can write the ncurses frontend (I think that's what you meant, correct me if I'm wrong) while I work on the various quickset profiles functional. Just in case you haven't been filled in yet, Mike's having me work on creating a few quickset profiles for swiftconfig, the idea being that sometimes its just easier to drop in a working set of configurations and tweaking from there rather than starting from scratch every time. So far here are the profiles Mike came up with, and I've been working on:<br>
1) Remote execution via ssh, single site<br>2) Local execution via PBS, single site<br>3) Local execution via Coasters+PBS, single site<br>4) Remote execution via Coasters+SSH:PBS, single site<br><br>Templates for the sites.xml files for profiles 1-3 are ready, tested, and functional. I'm having issues getting 4 to work (see my correspondence with Mike in swift-devel), but that should hopefully get resolved today. After that, my major priority is to create and test a variety of multi-site profiles. The variety for these profiles is primarily going to come from the number of sites, the coaster settings, the specific scheduler used at each site, etc.. I don't have any particular thoughts on the specifics for these profiles, but I'll be working on that today.<br>
<br>In any case, let me know if I can help with anything.<br><br>Arjun<br>
</div><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Hello all,<br>
<br>
I am working on a utility to modify configuration files called
swiftconfig.<br>
This is still in the early stages, so there is a lot of room for changes
and<br>
new ideas. I believe there is some overlap between this project and what<br>
some other students will be doing this summer, so if anyone would like
to<br>
work with me on this, please feel free.<br>
<br>
I envision swiftconfig as a simple text-based configuration program. It
will<br>
be written in Perl and use the curses library for easier editing. It
should<br>
hopefully make swift configuration a little easier and prevent silly<br>
mistakes like typos in xml which could keep swift from running.
Everything<br>
that can be done within the editor should also be able to be done
directly<br>
from the command line. This should make it easier to expand upon in the<br>
future. For example, a web or GUI based application could be written
fairly<br>
quickly that would only need to call swiftconfig with the correct
command<br>
line options.<br>
<br>
There are three files swiftconfig can modify: tc.data, sites.xml, and<br>
auth.defaults.<br>
<br>
The options for transformation mode include<br>
<br>
-host # Host name<br>
-name # Translation name<br>
-path # Path to executable<br>
-profile # Profile arguments, defaults to null<br>
-tcfile # Location of tc file. If not specified, find tc.data<br>
based on location of swift<br>
-overwrite # If a duplicate is found, overwrite the old entry
without<br>
prompting<br>
<br>
Since platform and installation status are no longer used, they will
default<br>
to INTEL32::LINUX and INSTALLED.<br>
Here is an example of swiftconfig in transformation mode.<br>
<br>
$ swiftconfig -host localhost -name wc -path /usr/bin/wc<br>
<br>
tc.data should then have the line:<br>
localhost wc /usr/bin/wc INSTALLED INTEL32::LINUX null<br>
<br>
If there is already an entry with the name wc, it should prompt the user
to<br>
answer yes/no if the user wants to overwrite it (unless -overwrite is
given)<br>
<br>
For sites.xml, swiftconfig should allow the user to use existing
examples or<br>
specify their own. Here are the options:<br>
<br>
-template # Use existing commented example for defaults
(skynet,<br>
teraport, etc)<br>
-entry # Name of new entry (pool handle)<br>
-gridftp # Specify gridftp url<br>
-jobuniverse # Specify jobmanager universe<br>
-joburl # Specify jobmanager url<br>
-jobmajor # Specify jobmanager major value<br>
-jobminor # Specify jobmanager minor value<br>
-directory # Work directory<br>
-exprovider # Execution provider<br>
-exmanager # Execution job manager<br>
-exurl # Execution url<br>
-remove # Remove (comment out) an entry from sites.xml<br>
<br>
So, for example suppose a user has the following entry in sites.xml by<br>
default:<br>
<br>
<!--<br>
<pool handle="teraport" ><br>
<gridftp url="gsiftp://<a href="http://tp-grid1.uchicago.edu/" target="_blank">tp-grid1.uchicago.edu</a>" /><br>
<jobmanager universe="vanilla" url="<a href="http://tp-grid1.uchicago.edu/jobmanager-pbs" target="_blank">tp-grid1.uchicago.edu/jobmanager-pbs</a>"<br>
major="2" /><br>
<workdirectory >/home/tiberius/scratch/SWIFT-<div>WORK</workdirectory><br>
</pool><br>
--><br>
<br>
The command:<br>
<br>
$ swiftconfig -template teraport<br>
<br>
Which would uncomment that from sites.xml as is. The user could also
modify<br>
just a part of it:<br>
<br>
$ swiftconfig -template teraport -directory /tmp<br>
<br>
That should modify only the workdirectory and leave everything else the<br>
same.<br>
<br>
To create your own config, use -entry instead of -template<br>
<br>
$ swiftconfig -entry mynetwork -gridftp ftp.foo -exprovider gt4 (.. and
so<br>
on)<br>
<br>
The final mode of swiftconfig is for auth.log in ssh configurations.<br>
<br>
-auth # Set to auth mode<br>
-sshhost # Name of remote ssh host<br>
-sshmode # Either password or passphrase<br>
-sshuser # SSH username<br>
-sshpassword # SSH password<br>
-sshpassphrase # SSH passphrase<br>
-sshkey # Location of SSH key<br>
<br>
Any other ideas or suggestions on how swiftconfig should work are
welcome.<br>
<br>
David</div><br clear="all"><br></blockquote>-- <br>Arjun Comar, Rose-Hulman '12<br>