[Swift-devel] Proposed sites.xml management for 0.92 release

[Michael Wilde]

Yes, I think you can. If not, you can use lines like: 


#site workdirectory=/home/blah 


But I think site.workdidir should do. Best to try it to verify. Im pretty sure that properties just go into a namespace, and if no Java code looks at the name, its ignored. 


Two related points: 


- for workdir in particular I suggest a default of $(pwd)/work. A few other vars may have similar needs, but this is perhaps the only exception for now. 


- we can do a very simple core gensites implementation that is just a tad beyond Justin's prototype, to get started. Get templates from only one place (the release's etc/sites dir) and settings from only one place (swift.properties in the current directory). Then we can add a few more options and paths to match the spec. 


- the spec needs comment and review. We should distill the options down to a good match for what users need to do, without getting too complex. Typically two levels of templates ("swifts" and "mine") and two levels of settings ("my global settings" and "my (overriding) settings for this run directory"). 


Mike 



----- Original Message -----


To store their settings in swift.properties, can I safely create arbitrary values like gensites.workdirectory=/home/blah? 


On Mon, Feb 14, 2011 at 3:11 PM, Michael Wilde < wilde at mcs.anl.gov > wrote: 




The proposed gensites command is intended to be very simple. It basically takes a template and user-set variables, and inserts the variables into the template. 


The GenSites spec page proposed that templates can live in the release etc/sites dir, the users $HOME/.swift/sites dir, or a -T directory from the cmd line. User settings can live in swift.properties in the current dir or $HOME/.swift. Thats about it. I think this can be done simply and quickly in a shell script. 


- Mike 










On Mon, Feb 14, 2011 at 10:25 AM, Michael Wilde < wilde at mcs.anl.gov > wrote: 


Sarah, David, 

Yes, I think gathering the site templates is indeed the first step. Then parameterizing them, including provisions for removing lines (per the GetSites spec page). 

And I agree that we should set swiftrun aside (and later bundle any needed parts of it into the swift command). 

David, I reviewed the current swiftconfg, and I feel it can be greatly simplified by rewriting as a shell script. 


oh, if we're going to actually do a re-write rather than leverage the code david already wrote my preference would be for python over shell...david do you know python? if not then shell is *ok* with me, it'll just be a little slower and clumsier for me :P i thought if we were sticking with the perl i would not help write it but just write the doc, but if we're doing a re-write i'm guessing it will take the effort of both of is (?) 



There is some reasonable shell arg parsing logic we can lift from: 

https://svn.ci.uchicago.edu/svn/vdl2/SwiftApps/SwiftR/Swift/exec/start-swift 

(arg parsing is right after the usage() function around midway through the script) 

- Mike 





----- Original Message ----- 


sounds good to me david...i don't know perl so maybe my time would be better spent using it and updating the doc in sync with you working on the code (?) i think first we want to separate swiftconfig from swiftrun...it would be good if users who are already used to running regular 'swift' to be able to transition to using swiftconfig (i realize this probably affects the doc more than your code, i just wanted to mention it). 

so, maybe the first step is switching out the sites templates? 


On Fri, Feb 11, 2011 at 8:51 PM, David Kelly < dk0966 at cs.ship.edu > wrote: 


Would it be easier to modify the existing swiftconfig to adjust to the new format of templates? 


The main steps that were outlined are nearly already completed with swiftconfig 


- The commands are already there 
- A set of templates already exists, but would most likely be replaced with the ones verified by automated testing in the format Justin specified 
- A good start for documentation using swiftconfig on a variety of configurations is at http://www.ci.uchicago.edu/wiki/bin/view/SWFT/LearningSwift 
- Documentation for commands and syntax is there, swiftconfig -h and swiftrun -h 
- List all templates with swiftconfig -list templates (already knows the correct order of where to look for templates) 
- Help for specific templates is a good idea. That would be pretty straightforward to add 
- Support for applications and application groups is already there 


If we started over it seems like we would be duplicating a lot of code 






-- 
Michael Wilde 
Computation Institute, University of Chicago 
Mathematics and Computer Science Division 
Argonne National Laboratory 





-- 

Michael Wilde 
Computation Institute, University of Chicago 
Mathematics and Computer Science Division 
Argonne National Laboratory 





-- 
Michael Wilde 
Computation Institute, University of Chicago 
Mathematics and Computer Science Division 
Argonne National Laboratory 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20110215/e6aa936a/attachment.html>