From benc at hawaga.org.uk Sat Sep 1 06:46:21 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Sat, 1 Sep 2007 11:46:21 +0000 (GMT) Subject: [Swift-devel] Re: latest Falkon code is in SVN! In-Reply-To: <1188568435.12219.0.camel@blabla.mcs.anl.gov> References: <46D4970E.4000809@cs.uchicago.edu> <46D4A46C.6070806@mcs.anl.gov> <46D4AB05.9070900@cs.uchicago.edu> <1188568435.12219.0.camel@blabla.mcs.anl.gov> Message-ID: Even better would be if the code that I assume came from Ioan's build wasn't in the SVN in compiled form at all - I started playing at that removing some of the precompiled .jar files in there, but something isn't getting rebuilt properly so I need to play some more. On Fri, 31 Aug 2007, Mihael Hategan wrote: > Use javac -source 1.4 -target 1.4 when compiling. > > On Fri, 2007-08-31 at 10:53 +0000, Ben Clifford wrote: > > When I run the client, I get this error, which looks like maybe you've got > > some pre-compiled code that is compiled with something later than the 1.5 > > JDK that I use... > > > > 2007-08-31 11:50:59,646 ERROR container.ServiceThread > > [ServiceThread-2,run:297] Unexpected error during request processing > > java.lang.UnsupportedClassVersionError: Bad version number in .class file > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > > at > > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > > at java.net.URLClassLoader.access$100(URLClassLoader.java:56) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:306) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:251) > > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:242) > > at org.apache.axis.utils.ClassUtils$2.run(ClassUtils.java:176) > > at java.security.AccessController.doPrivileged(Native Method) > > at org.apache.axis.utils.ClassUtils.loadClass(ClassUtils.java:160) > > at org.apache.axis.utils.ClassUtils.forName(ClassUtils.java:142) > > at > > org.apache.axis.utils.cache.ClassCache.lookup(ClassCache.java:85) > > at > > org.apache.axis.providers.java.JavaProvider.getServiceClass(JavaProvider.java:424) > > at > > org.apache.axis.providers.java.JavaProvider.initServiceDesc(JavaProvider.java:457) > > at > > org.apache.axis.handlers.soap.SOAPService.getInitializedServiceDesc(SOAPService.java:283) > > at > > org.apache.axis.deployment.wsdd.WSDDService.makeNewInstance(WSDDService.java:487) > > at > > org.apache.axis.deployment.wsdd.WSDDDeployableItem.getNewInstance(WSDDDeployableItem.java:274) > > at > > org.apache.axis.deployment.wsdd.WSDDDeployableItem.getInstance(WSDDDeployableItem.java:260) > > at > > org.apache.axis.deployment.wsdd.WSDDDeployment.getService(WSDDDeployment.java:478) > > at > > org.apache.axis.configuration.DirProvider.getService(DirProvider.java:156) > > at org.apache.axis.AxisEngine.getService(AxisEngine.java:323) > > at > > org.apache.axis.MessageContext.setTargetService(MessageContext.java:757) > > at > > org.globus.wsrf.handlers.AddressingHandler.setTargetService(AddressingHandler.java:152) > > at > > org.apache.axis.message.addressing.handler.AddressingHandler.processServerRequest(AddressingHandler.java:344) > > at > > org.globus.wsrf.handlers.AddressingHandler.processServerRequest(AddressingHandler.java:77) > > at > > org.apache.axis.message.addressing.handler.AddressingHandler.invoke(AddressingHandler.java:114) > > at > > org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) > > at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) > > at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) > > at org.apache.axis.server.AxisServer.invoke(AxisServer.java:248) > > at > > org.globus.wsrf.container.ServiceThread.doPost(ServiceThread.java:664) > > at > > org.globus.wsrf.container.ServiceThread.process(ServiceThread.java:382) > > at > > org.globus.wsrf.container.ServiceThread.run(ServiceThread.java:291) > > > > > > From iraicu at cs.uchicago.edu Sat Sep 1 08:21:35 2007 From: iraicu at cs.uchicago.edu (Ioan Raicu) Date: Sat, 01 Sep 2007 08:21:35 -0500 Subject: [Swift-devel] Re: latest Falkon code is in SVN! In-Reply-To: References: <46D4970E.4000809@cs.uchicago.edu> <46D4A46C.6070806@mcs.anl.gov> <46D4AB05.9070900@cs.uchicago.edu> <1188568435.12219.0.camel@blabla.mcs.anl.gov> Message-ID: <46D9675F.1010706@cs.uchicago.edu> I thought the clean scripts cleaned everything up, which I did before I did a commit! I guess not, I'll look into it. Ioan Ben Clifford wrote: > Even better would be if the code that I assume came from Ioan's build > wasn't in the SVN in compiled form at all - I started playing at that > removing some of the precompiled .jar files in there, but something isn't > getting rebuilt properly so I need to play some more. > > On Fri, 31 Aug 2007, Mihael Hategan wrote: > > >> Use javac -source 1.4 -target 1.4 when compiling. >> >> On Fri, 2007-08-31 at 10:53 +0000, Ben Clifford wrote: >> >>> When I run the client, I get this error, which looks like maybe you've got >>> some pre-compiled code that is compiled with something later than the 1.5 >>> JDK that I use... >>> >>> 2007-08-31 11:50:59,646 ERROR container.ServiceThread >>> [ServiceThread-2,run:297] Unexpected error during request processing >>> java.lang.UnsupportedClassVersionError: Bad version number in .class file >>> at java.lang.ClassLoader.defineClass1(Native Method) >>> at java.lang.ClassLoader.defineClass(ClassLoader.java:620) >>> at >>> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) >>> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) >>> at java.net.URLClassLoader.access$100(URLClassLoader.java:56) >>> at java.net.URLClassLoader$1.run(URLClassLoader.java:195) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at java.net.URLClassLoader.findClass(URLClassLoader.java:188) >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306) >>> at java.lang.ClassLoader.loadClass(ClassLoader.java:251) >>> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) >>> at java.lang.Class.forName0(Native Method) >>> at java.lang.Class.forName(Class.java:242) >>> at org.apache.axis.utils.ClassUtils$2.run(ClassUtils.java:176) >>> at java.security.AccessController.doPrivileged(Native Method) >>> at org.apache.axis.utils.ClassUtils.loadClass(ClassUtils.java:160) >>> at org.apache.axis.utils.ClassUtils.forName(ClassUtils.java:142) >>> at >>> org.apache.axis.utils.cache.ClassCache.lookup(ClassCache.java:85) >>> at >>> org.apache.axis.providers.java.JavaProvider.getServiceClass(JavaProvider.java:424) >>> at >>> org.apache.axis.providers.java.JavaProvider.initServiceDesc(JavaProvider.java:457) >>> at >>> org.apache.axis.handlers.soap.SOAPService.getInitializedServiceDesc(SOAPService.java:283) >>> at >>> org.apache.axis.deployment.wsdd.WSDDService.makeNewInstance(WSDDService.java:487) >>> at >>> org.apache.axis.deployment.wsdd.WSDDDeployableItem.getNewInstance(WSDDDeployableItem.java:274) >>> at >>> org.apache.axis.deployment.wsdd.WSDDDeployableItem.getInstance(WSDDDeployableItem.java:260) >>> at >>> org.apache.axis.deployment.wsdd.WSDDDeployment.getService(WSDDDeployment.java:478) >>> at >>> org.apache.axis.configuration.DirProvider.getService(DirProvider.java:156) >>> at org.apache.axis.AxisEngine.getService(AxisEngine.java:323) >>> at >>> org.apache.axis.MessageContext.setTargetService(MessageContext.java:757) >>> at >>> org.globus.wsrf.handlers.AddressingHandler.setTargetService(AddressingHandler.java:152) >>> at >>> org.apache.axis.message.addressing.handler.AddressingHandler.processServerRequest(AddressingHandler.java:344) >>> at >>> org.globus.wsrf.handlers.AddressingHandler.processServerRequest(AddressingHandler.java:77) >>> at >>> org.apache.axis.message.addressing.handler.AddressingHandler.invoke(AddressingHandler.java:114) >>> at >>> org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) >>> at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) >>> at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) >>> at org.apache.axis.server.AxisServer.invoke(AxisServer.java:248) >>> at >>> org.globus.wsrf.container.ServiceThread.doPost(ServiceThread.java:664) >>> at >>> org.globus.wsrf.container.ServiceThread.process(ServiceThread.java:382) >>> at >>> org.globus.wsrf.container.ServiceThread.run(ServiceThread.java:291) >>> >>> >>> >> > > -- ============================================ Ioan Raicu Ph.D. Student ============================================ Distributed Systems Laboratory Computer Science Department University of Chicago 1100 E. 58th Street, Ryerson Hall Chicago, IL 60637 ============================================ Email: iraicu at cs.uchicago.edu Web: http://www.cs.uchicago.edu/~iraicu http://dsl.cs.uchicago.edu/ ============================================ ============================================ -------------- next part -------------- An HTML attachment was scrubbed... URL: From benc at hawaga.org.uk Sat Sep 1 08:26:03 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Sat, 1 Sep 2007 13:26:03 +0000 (GMT) Subject: [Swift-devel] Re: latest Falkon code is in SVN! In-Reply-To: <46D9675F.1010706@cs.uchicago.edu> References: <46D4970E.4000809@cs.uchicago.edu> <46D4A46C.6070806@mcs.anl.gov> <46D4AB05.9070900@cs.uchicago.edu> <1188568435.12219.0.camel@blabla.mcs.anl.gov> <46D9675F.1010706@cs.uchicago.edu> Message-ID: On Sat, 1 Sep 2007, Ioan Raicu wrote: > I thought the clean scripts cleaned everything up, which I did before I did a > commit! I guess not, I'll look into it. If a file is in SVN already, it needs to be removed with 'svn rm' in addition to removing from the local checkout with rm. My initial import of falkon was not particularly clean, so there's plenty of stuff that needs tidying there. -- From tiberius at ci.uchicago.edu Mon Sep 3 04:11:00 2007 From: tiberius at ci.uchicago.edu (Tiberiu Stef-Praun) Date: Mon, 3 Sep 2007 12:11:00 +0300 Subject: [Swift-devel] Re: [Bug 89] Use unique package names! In-Reply-To: References: <20070830010420.0B0DB16506@foxtrot.mcs.anl.gov> Message-ID: org.globus.swift On 8/30/07, Ben Clifford wrote: > > > On Wed, 29 Aug 2007, bugzilla-daemon at mcs.anl.gov wrote: > > > 1. edu.uchicago.ci.swift? > > 2. gov.anl.mcs.swift? > > 3. org.globus.swift? > > 4. org.globus.cog.swift? :) > > > > Please vote. > > Note that the swift group doesn't own any of those names so really should > be co-ordinated with whoever. > > I'd prefer option 3. > > -- > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel > -- Tiberiu (Tibi) Stef-Praun, PhD Research Staff, Computation Institute 5640 S. Ellis Ave, #405 University of Chicago http://www-unix.mcs.anl.gov/~tiberius/ From benc at hawaga.org.uk Mon Sep 3 05:41:26 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 10:41:26 +0000 (GMT) Subject: [Swift-devel] ant build for service Message-ID: I started working on moving the falkon build to use ant. The present (as of r1166) falkon/service/make.gpws.sh script will now invoke an ant build file that should do roughly the same as the previous all-bash one. -- From benc at hawaga.org.uk Mon Sep 3 06:25:41 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 11:25:41 +0000 (GMT) Subject: [Swift-devel] IllegalThreadStateException Message-ID: I get these: WORKER:NotificationThread:readThread:doRun(): if(CACHING == false) WORKER:NotificationThread:readThread:doRun(): taskFileName = some data file name Executing task soju.hawaga.org.uk:50102:10_1011162150... Building executable command...Executing: sleep 1 Environment: Working Directory: java.lang.IllegalThreadStateException: process hasn't exited at java.lang.UNIXProcess.exitValue(UNIXProcess.java:119) at org.globus.GenericPortal.clients.GPService_instance.ExecThread.exec(WorkerRun.java:3159) at org.globus.GenericPortal.clients.GPService_instance.ExecThread.doRun(WorkerRun.java:3380) at org.globus.GenericPortal.clients.GPService_instance.ExecThread.run(WorkerRun.java:2918) starting ChildListener thread... polling ChildListener thread for termination... in large number (once per task?) when I try out your example localhost sleep examples... -- From benc at hawaga.org.uk Mon Sep 3 06:35:18 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 11:35:18 +0000 (GMT) Subject: [Swift-devel] Re: IllegalThreadStateException In-Reply-To: References: Message-ID: slightly scarily, the source code looks like that's deliberate? On Mon, 3 Sep 2007, Ben Clifford wrote: > > I get these: > > WORKER:NotificationThread:readThread:doRun(): if(CACHING == false) > WORKER:NotificationThread:readThread:doRun(): taskFileName = some data > file name > Executing task soju.hawaga.org.uk:50102:10_1011162150... Building > executable command...Executing: sleep 1 > Environment: > Working Directory: java.lang.IllegalThreadStateException: process hasn't > exited > at java.lang.UNIXProcess.exitValue(UNIXProcess.java:119) > at > org.globus.GenericPortal.clients.GPService_instance.ExecThread.exec(WorkerRun.java:3159) > at > org.globus.GenericPortal.clients.GPService_instance.ExecThread.doRun(WorkerRun.java:3380) > at > org.globus.GenericPortal.clients.GPService_instance.ExecThread.run(WorkerRun.java:2918) > starting ChildListener thread... > polling ChildListener thread for termination... > > in large number (once per task?) when I try out your example localhost > sleep examples... > > From benc at hawaga.org.uk Mon Sep 3 07:29:15 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 12:29:15 +0000 (GMT) Subject: [Swift-devel] Re: IllegalThreadStateException In-Reply-To: References: Message-ID: I reworked some of that code in r1171 to avoid exceptions. -- From benc at hawaga.org.uk Mon Sep 3 10:31:37 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 15:31:37 +0000 (GMT) Subject: [Swift-devel] xml-intermediate-language branch Message-ID: branches/xml-intermediate-language has the latest set of changes I want to put in to make the XML intermediate language more xml-structured and less ad-hoc. for users, there shouldn't be immediate changes in already-working behaviour; more stuff that intuitively should work will now work, removing the need for some workarounds in programs where expressions don't work in certain places - there are a number of bugs which this code will fix. it seems to work OK in the testing I've done. I'm going to do more testing on larger programs over the next few days and if that goes OK then put it in trunk towards the end of this week. if you test the code in xml-intermediate-language branch, you'll give me a chance to fix your problems before you get screwed by them when I merge to trunk. you can do this by following the usual build-from-SVN instructions at http://www.ci.uchicago.edu/swift/downloads/index.php but replace the checkout-swift svn command with: (on one line) svn co https://svn.ci.uchicago.edu/svn/vdl2/branches/xml-intermediate-language vdsk (the difference being that the URL ends branches/xml-intermediate-language rather than trunk) -- From hategan at mcs.anl.gov Mon Sep 3 11:19:57 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 03 Sep 2007 11:19:57 -0500 Subject: [Swift-devel] Re: IllegalThreadStateException In-Reply-To: References: Message-ID: <1188836397.11145.2.camel@blabla.mcs.anl.gov> On Mon, 2007-09-03 at 11:35 +0000, Ben Clifford wrote: > slightly scarily, the source code looks like that's deliberate? Yes. Java has no other way of telling whether a process is done or still running, unless you create another thread and use Process.waitFor. See http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Process.html#exitValue() > > On Mon, 3 Sep 2007, Ben Clifford wrote: > > > > > I get these: > > > > WORKER:NotificationThread:readThread:doRun(): if(CACHING == false) > > WORKER:NotificationThread:readThread:doRun(): taskFileName = some data > > file name > > Executing task soju.hawaga.org.uk:50102:10_1011162150... Building > > executable command...Executing: sleep 1 > > Environment: > > Working Directory: java.lang.IllegalThreadStateException: process hasn't > > exited > > at java.lang.UNIXProcess.exitValue(UNIXProcess.java:119) > > at > > org.globus.GenericPortal.clients.GPService_instance.ExecThread.exec(WorkerRun.java:3159) > > at > > org.globus.GenericPortal.clients.GPService_instance.ExecThread.doRun(WorkerRun.java:3380) > > at > > org.globus.GenericPortal.clients.GPService_instance.ExecThread.run(WorkerRun.java:2918) > > starting ChildListener thread... > > polling ChildListener thread for termination... > > > > in large number (once per task?) when I try out your example localhost > > sleep examples... > > > > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel > From benc at hawaga.org.uk Mon Sep 3 11:23:57 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 16:23:57 +0000 (GMT) Subject: [Swift-devel] Re: IllegalThreadStateException In-Reply-To: <1188836397.11145.2.camel@blabla.mcs.anl.gov> References: <1188836397.11145.2.camel@blabla.mcs.anl.gov> Message-ID: On Mon, 3 Sep 2007, Mihael Hategan wrote: > On Mon, 2007-09-03 at 11:35 +0000, Ben Clifford wrote: > > slightly scarily, the source code looks like that's deliberate? > > Yes. Java has no other way of telling whether a process is done or still > running, unless you create another thread and use Process.waitFor. See > http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Process.html#exitValue() That's happening anyway, in ChildListener which is in WorkerRun.java. -- From benc at hawaga.org.uk Mon Sep 3 12:24:57 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 17:24:57 +0000 (GMT) Subject: [Swift-devel] Cant get Falkon provider connected to Swift In-Reply-To: <46D80323.1070009@mcs.anl.gov> References: <46D7571F.2010605@mcs.anl.gov> <1188520501.18147.11.camel@blabla.mcs.anl.gov> <1188522138.18147.22.camel@blabla.mcs.anl.gov> <46D76A90.40700@mcs.anl.gov> <46D80323.1070009@mcs.anl.gov> Message-ID: On Fri, 31 Aug 2007, Michael Wilde wrote: > Found the problem: I had been using symlinks from the swift etc dir to my > local sites and tc files, and set the links wrong when I switched to the > falkon-enabled build. Its running now - thanks. on a related note, you can configure the sites and tc files per user-account by making a .swift directory and putting property specifications in there, like this: $ cat ~train01/.swift/swift.properties sites.file=${user.home}/sites.xml tc.file=${user.home}/tc.data -- From benc at hawaga.org.uk Mon Sep 3 13:53:24 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 18:53:24 +0000 (GMT) Subject: [Swift-devel] documenting sites.xml Message-ID: I was wondering about the best way to provide reference material for sites.xml (and a future XML-based tc.data rewrite). At present, sites.xml is a karajan code fragment document rather than an XSD-compliant document (which manifests itself primarily in the handling of namespaces). If it was an XSD-compliant file, then I'd use an XSD -> documentation tool and put the descriptions in there. Is there any established convention for doing something like this with karajan elements? -- From foster at mcs.anl.gov Mon Sep 3 14:28:32 2007 From: foster at mcs.anl.gov (Ian Foster) Date: Mon, 03 Sep 2007 14:28:32 -0500 Subject: [Swift-devel] documenting sites.xml In-Reply-To: References: Message-ID: <46DC6060.3030708@mcs.anl.gov> A comment: I think it is important that we document this for two audiences: U.Chicago-based people (who can hopefully used a pre-installed version) and external people. Ben Clifford wrote: > I was wondering about the best way to provide reference material for > sites.xml (and a future XML-based tc.data rewrite). > > At present, sites.xml is a karajan code fragment document rather than an > XSD-compliant document (which manifests itself primarily in the handling > of namespaces). If it was an XSD-compliant file, then I'd use an XSD -> > documentation tool and put the descriptions in there. > > Is there any established convention for doing something like this with > karajan elements? > > -- Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619. Web: www.ci.uchicago.edu. Globus Alliance: www.globus.org. From hategan at mcs.anl.gov Mon Sep 3 14:42:35 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 03 Sep 2007 14:42:35 -0500 Subject: [Swift-devel] documenting sites.xml In-Reply-To: References: Message-ID: <1188848555.18065.5.camel@blabla.mcs.anl.gov> On Mon, 2007-09-03 at 18:53 +0000, Ben Clifford wrote: > I was wondering about the best way to provide reference material for > sites.xml (and a future XML-based tc.data rewrite). > > At present, sites.xml is a karajan code fragment document rather than an > XSD-compliant document (which manifests itself primarily in the handling > of namespaces). If it was an XSD-compliant file, then I'd use an XSD -> > documentation tool and put the descriptions in there. What exactly is the difference? > > Is there any established convention for doing something like this with > karajan elements? Basically, no. The documentation is somewhat flat, as in it doesn't have any structure describing mechanism besides spelling things out. > From benc at hawaga.org.uk Mon Sep 3 14:50:28 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 19:50:28 +0000 (GMT) Subject: [Swift-devel] documenting sites.xml In-Reply-To: <1188848555.18065.5.camel@blabla.mcs.anl.gov> References: <1188848555.18065.5.camel@blabla.mcs.anl.gov> Message-ID: On Mon, 3 Sep 2007, Mihael Hategan wrote: > > At present, sites.xml is a karajan code fragment document rather than an > > XSD-compliant document (which manifests itself primarily in the handling > > of namespaces). If it was an XSD-compliant file, then I'd use an XSD -> > > documentation tool and put the descriptions in there. > > What exactly is the difference? karajan namespace handling appears to work quite differently from XSD (traditional XML namespace handling). in XSD, a sites file beginning: would be the same as and would not be the same as (with s:prefix put on all the elements) But in the Karajan implementation: Execution failed: 's:pool' is not defined. Less relevantly in this particular situation, the defaulting works differently too - defining an element in a different namespace can cause a non-labelled element to mean something different in karajan, which doesn't happen in XML Namespaces. -- From hategan at mcs.anl.gov Mon Sep 3 17:19:58 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 03 Sep 2007 17:19:58 -0500 Subject: [Swift-devel] documenting sites.xml In-Reply-To: References: <1188848555.18065.5.camel@blabla.mcs.anl.gov> Message-ID: <1188857998.23446.7.camel@blabla.mcs.anl.gov> Right. The karajan namespaces are more like java namespaces. But I'm not sure I agree with the last part of what you say. Ambiguities cause errors (as in Java). Which means that you can't remap namespaces where you use them. There are a few possibilities: 1. We document the way it works and forget the schema (most likely finding meaning in an XML schema is not for the faint of heart). 2. We parse and verify the XML using a validating parser and generate the relevant objects from that (this is the correct, but difficult path) 3. Karajan is adapted to do namespace remapping and we combine this with a validator. Mihael On Mon, 2007-09-03 at 19:50 +0000, Ben Clifford wrote: > > On Mon, 3 Sep 2007, Mihael Hategan wrote: > > > > At present, sites.xml is a karajan code fragment document rather than an > > > XSD-compliant document (which manifests itself primarily in the handling > > > of namespaces). If it was an XSD-compliant file, then I'd use an XSD -> > > > documentation tool and put the descriptions in there. > > > > What exactly is the difference? > > karajan namespace handling appears to work quite differently from XSD > (traditional XML namespace handling). > > in XSD, a sites file beginning: > > > > would be the same as > > > > and would not be the same as > > > > (with s:prefix put on all the elements) > > But in the Karajan implementation: > > Execution failed: > 's:pool' is not defined. > > > Less relevantly in this particular situation, the defaulting works > differently too - defining an element in a different namespace can cause a > non-labelled element to mean something different in karajan, which doesn't > happen in XML Namespaces. > From benc at hawaga.org.uk Mon Sep 3 17:31:41 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 22:31:41 +0000 (GMT) Subject: [Swift-devel] documenting sites.xml In-Reply-To: <1188857998.23446.7.camel@blabla.mcs.anl.gov> References: <1188848555.18065.5.camel@blabla.mcs.anl.gov> <1188857998.23446.7.camel@blabla.mcs.anl.gov> Message-ID: On Mon, 3 Sep 2007, Mihael Hategan wrote: > But I'm not sure I agree with the last part of what you say. Ambiguities > cause errors (as in Java). this bit? : >> defining an element in a different namespace can cause a non-labelled >> element to mean something different in karajan, which doesn't happen in >> XML Namespaces. There aren't ambiguities in XML namespace handling there. If a namespace prefix is used without being mapped somewhere (either the very small set of default mappings, or explicitly in an enclosing element) then the document is not valid. -- From benc at hawaga.org.uk Mon Sep 3 17:32:47 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Mon, 3 Sep 2007 22:32:47 +0000 (GMT) Subject: [Swift-devel] documenting sites.xml In-Reply-To: <1188857998.23446.7.camel@blabla.mcs.anl.gov> References: <1188848555.18065.5.camel@blabla.mcs.anl.gov> <1188857998.23446.7.camel@blabla.mcs.anl.gov> Message-ID: On Mon, 3 Sep 2007, Mihael Hategan wrote: > 1. We document the way it works and forget the schema (most likely > finding meaning in an XML schema is not for the faint of heart). That's probably the approach for now. However, if later on people want to do machine processing of the sites file (for example, machine generation using XML libraries) they might (or might not) run into problems. -- From hategan at mcs.anl.gov Mon Sep 3 18:51:57 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 03 Sep 2007 18:51:57 -0500 Subject: [Swift-devel] documenting sites.xml In-Reply-To: References: <1188848555.18065.5.camel@blabla.mcs.anl.gov> <1188857998.23446.7.camel@blabla.mcs.anl.gov> Message-ID: <1188863517.26844.2.camel@blabla.mcs.anl.gov> On Mon, 2007-09-03 at 22:31 +0000, Ben Clifford wrote: > On Mon, 3 Sep 2007, Mihael Hategan wrote: > > > But I'm not sure I agree with the last part of what you say. Ambiguities > > cause errors (as in Java). > > this bit? : Oh, I see. What you're saying is that an element without a namespace will not default to a certain namespace even if there are no ambiguities in that choice. Which I don't know exactly about XML, but in Karajan that default will happen. > > >> defining an element in a different namespace can cause a non-labelled > >> element to mean something different in karajan, which doesn't happen in > >> XML Namespaces. > > There aren't ambiguities in XML namespace handling there. If a namespace > prefix is used without being mapped somewhere (either the very small set > of default mappings, or explicitly in an enclosing element) then the > document is not valid. Right. > From hategan at mcs.anl.gov Mon Sep 3 18:55:28 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Mon, 03 Sep 2007 18:55:28 -0500 Subject: [Swift-devel] documenting sites.xml In-Reply-To: References: <1188848555.18065.5.camel@blabla.mcs.anl.gov> <1188857998.23446.7.camel@blabla.mcs.anl.gov> Message-ID: <1188863728.26844.7.camel@blabla.mcs.anl.gov> On Mon, 2007-09-03 at 22:32 +0000, Ben Clifford wrote: > > On Mon, 3 Sep 2007, Mihael Hategan wrote: > > > 1. We document the way it works and forget the schema (most likely > > finding meaning in an XML schema is not for the faint of heart). > > That's probably the approach for now. However, if later on people want to > do machine processing of the sites file (for example, machine generation > using XML libraries) they might (or might not) run into problems. > That *is* the approach for now. From wilde at mcs.anl.gov Tue Sep 4 11:18:21 2007 From: wilde at mcs.anl.gov (Michael Wilde) Date: Tue, 04 Sep 2007 11:18:21 -0500 Subject: [Swift-devel] Cant get Falkon provider connected to Swift In-Reply-To: References: <46D7571F.2010605@mcs.anl.gov> <1188520501.18147.11.camel@blabla.mcs.anl.gov> <1188522138.18147.22.camel@blabla.mcs.anl.gov> <46D76A90.40700@mcs.anl.gov> <46D80323.1070009@mcs.anl.gov> Message-ID: <46DD854D.502@mcs.anl.gov> Excellent - exactly what I need. Can you put this in the users guide if its not there already? (I may have missed it, if it is). On a related note, I think I experienced surprising behavior in how the swift command parses properties on the command line. I had things in an odd order, and it seemed to silently ignore throttling properties that were placed after the swift file name, and not accept them when I moved them where they belong, before the swift file name. They worked fine when I put then in the properties file. I need to capture the specific cases before I can file a bug on them, but I had to move on. Thanks, Mike Ben Clifford wrote: > > On Fri, 31 Aug 2007, Michael Wilde wrote: > >> Found the problem: I had been using symlinks from the swift etc dir to my >> local sites and tc files, and set the links wrong when I switched to the >> falkon-enabled build. Its running now - thanks. > > on a related note, you can configure the sites and tc files per > user-account by making a .swift directory and putting property > specifications in there, like this: > > $ cat ~train01/.swift/swift.properties > sites.file=${user.home}/sites.xml > tc.file=${user.home}/tc.data > From hategan at mcs.anl.gov Tue Sep 4 11:36:00 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 04 Sep 2007 11:36:00 -0500 Subject: [Swift-devel] Cant get Falkon provider connected to Swift In-Reply-To: <46DD854D.502@mcs.anl.gov> References: <46D7571F.2010605@mcs.anl.gov> <1188520501.18147.11.camel@blabla.mcs.anl.gov> <1188522138.18147.22.camel@blabla.mcs.anl.gov> <46D76A90.40700@mcs.anl.gov> <46D80323.1070009@mcs.anl.gov> <46DD854D.502@mcs.anl.gov> Message-ID: <1188923760.32613.5.camel@blabla.mcs.anl.gov> On Tue, 2007-09-04 at 11:18 -0500, Michael Wilde wrote: > Excellent - exactly what I need. Can you put this in the users guide if > its not there already? (I may have missed it, if it is). > > On a related note, I think I experienced surprising behavior in how the > swift command parses properties on the command line. I had things in an > odd order, and it seemed to silently ignore throttling properties that > were placed after the swift file name, and not accept them when I moved > them where they belong, before the swift file name. They worked fine > when I put then in the properties file. I think -help describes things pretty clearly, although, perhaps "arguments" should be replaced with "workflow arguments": swift file If you put them after the file, then they are passed to the workflow. If you put them before you'll get an error because the throttling properties cannot be set from the command line. > > I need to capture the specific cases before I can file a bug on them, > but I had to move on. > > Thanks, > > Mike > > Ben Clifford wrote: > > > > On Fri, 31 Aug 2007, Michael Wilde wrote: > > > >> Found the problem: I had been using symlinks from the swift etc dir to my > >> local sites and tc files, and set the links wrong when I switched to the > >> falkon-enabled build. Its running now - thanks. > > > > on a related note, you can configure the sites and tc files per > > user-account by making a .swift directory and putting property > > specifications in there, like this: > > > > $ cat ~train01/.swift/swift.properties > > sites.file=${user.home}/sites.xml > > tc.file=${user.home}/tc.data > > > From hategan at mcs.anl.gov Tue Sep 4 11:50:07 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 04 Sep 2007 11:50:07 -0500 Subject: [Swift-devel] Cant get Falkon provider connected to Swift In-Reply-To: <46DD8B46.5060400@mcs.anl.gov> References: <46D7571F.2010605@mcs.anl.gov> <1188520501.18147.11.camel@blabla.mcs.anl.gov> <1188522138.18147.22.camel@blabla.mcs.anl.gov> <46D76A90.40700@mcs.anl.gov> <46D80323.1070009@mcs.anl.gov> <46DD854D.502@mcs.anl.gov> <1188923760.32613.5.camel@blabla.mcs.anl.gov> <46DD8B46.5060400@mcs.anl.gov> Message-ID: <1188924608.815.4.camel@blabla.mcs.anl.gov> On Tue, 2007-09-04 at 11:43 -0500, Michael Wilde wrote: > > Mihael Hategan wrote: > ... the throttling > > properties cannot be set from the command line. > > OK. So its intentional that some but not all properties can be set from > the command line? Is that by intent, or just that it takes extra coding > to accept them, and its not been done yet? It was done in order to keep the number of command line arguments, and hence the size of what's printed when doing -help, to a sane value. The choice of what to put in there was more or less dictated by what one would be most likely to change from run to run, but then also things closely related (having kickstart.enabled without kickstart.always.transfer may have been a bit surprising). > > - Mike > From benc at hawaga.org.uk Tue Sep 4 12:58:59 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Tue, 4 Sep 2007 17:58:59 +0000 (GMT) Subject: [Swift-devel] Cant get Falkon provider connected to Swift In-Reply-To: <1188923760.32613.5.camel@blabla.mcs.anl.gov> References: <46D7571F.2010605@mcs.anl.gov> <1188520501.18147.11.camel@blabla.mcs.anl.gov> <1188522138.18147.22.camel@blabla.mcs.anl.gov> <46D76A90.40700@mcs.anl.gov> <46D80323.1070009@mcs.anl.gov> <46DD854D.502@mcs.anl.gov> <1188923760.32613.5.camel@blabla.mcs.anl.gov> Message-ID: On Tue, 4 Sep 2007, Mihael Hategan wrote: > I think -help describes things pretty clearly though that's not what the principle of least surprise is about -- its possible to document anything. 'ls foo -t' doesn't work like 'ls -t foo' on os x, and is repeatedly surprising to me despite the fact that it is documented. -- From hategan at mcs.anl.gov Tue Sep 4 14:11:49 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 04 Sep 2007 14:11:49 -0500 Subject: [Swift-devel] Cant get Falkon provider connected to Swift In-Reply-To: References: <46D7571F.2010605@mcs.anl.gov> <1188520501.18147.11.camel@blabla.mcs.anl.gov> <1188522138.18147.22.camel@blabla.mcs.anl.gov> <46D76A90.40700@mcs.anl.gov> <46D80323.1070009@mcs.anl.gov> <46DD854D.502@mcs.anl.gov> <1188923760.32613.5.camel@blabla.mcs.anl.gov> Message-ID: <1188933109.2364.3.camel@blabla.mcs.anl.gov> On Tue, 2007-09-04 at 17:58 +0000, Ben Clifford wrote: > > On Tue, 4 Sep 2007, Mihael Hategan wrote: > > > I think -help describes things pretty clearly > > though that's not what the principle of least surprise is about -- its > possible to document anything. 'ls foo -t' doesn't work like 'ls -t foo' > on os x, and is repeatedly surprising to me despite the fact that it is > documented. Right, but the principle applies to the level of flexibility a system provides, not to whatever the current user thinks the system should do at that very moment. The extreme of this is the "do what I want" switch. We all agree that is the least surprising of them all. Unfortunately there is no known implementation for it. > From hategan at mcs.anl.gov Tue Sep 4 21:11:38 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Tue, 04 Sep 2007 21:11:38 -0500 Subject: [Swift-devel] wrapper and vdl-int.k updates Message-ID: <1188958298.26058.12.camel@blabla.mcs.anl.gov> The better error handling is in. Basically a few things were changed: - The wrapper needs to always signal completion (whether successful or not). Absence of such a signal is an error, most likely a shared filesystem error. - No more weird exit codes. Nice error messages are now sent by the wrapper. - Most operations done by the wrapper are error-checked. That includes directory creation, removal, copying, whether the executable exists, etc. - If the application says it ran successfully, but some output files are missing, the resulting error nicely lists all of them (missing ones). - Info files in ${workflow directory}/info/${jobid}-info (uname, id, env, df, /proc/cpuinfo, /proc/meminfo). These are simply collected on the remote site for now, but it's better than nothing (since it seems folks don't want to be bothered installing/finding kickstart). This needs to be tested, as usual. Mihael From benc at hawaga.org.uk Wed Sep 5 02:41:45 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Wed, 5 Sep 2007 07:41:45 +0000 (GMT) Subject: [Swift-devel] wrapper and vdl-int.k updates In-Reply-To: <1188958298.26058.12.camel@blabla.mcs.anl.gov> References: <1188958298.26058.12.camel@blabla.mcs.anl.gov> Message-ID: it would be nice if wrapper.sh moved away from having such sensitive argument handling that it needs very precise quoting (eg the ability to pass through empty arguments in the middle of the argument list) that poorly survives going through some execution systems (I think I've seen it cause trouble going through gram2+condor). -- From benc at hawaga.org.uk Wed Sep 5 05:38:27 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Wed, 5 Sep 2007 10:38:27 +0000 (GMT) Subject: [Swift-devel] hands on swift tutorial on CI machines Message-ID: As part of OSG education and training, it was straightforward to produce a separate swift-only hands on lab page, which is now available at http://www.ci.uchicago.edu/osgedu/schools/swiftlab/ and linked from the docs page. There will be more introductory material there about how to get an account, in time. -- From benc at hawaga.org.uk Wed Sep 5 09:14:57 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Wed, 5 Sep 2007 14:14:57 +0000 (GMT) Subject: [Swift-devel] latest Falkon code is in SVN! In-Reply-To: <46D58A3B.8050702@cs.uchicago.edu> References: <46D4970E.4000809@cs.uchicago.edu> <46D58A3B.8050702@cs.uchicago.edu> Message-ID: On Wed, 29 Aug 2007, Ioan Raicu wrote: > BTW, about the particular error you saw, the C Executor is a new experimental > implementation that could replace the Java based worker code and WS-based > communication protocol. As part of my on-going playing with the falkon build system, I removed the code to build that from worker/make.worker.sh and put it in make.worker-c.sh (as of r1194). The top-level falkon build will now not build the C code. -- From hategan at mcs.anl.gov Wed Sep 5 10:19:49 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 05 Sep 2007 10:19:49 -0500 Subject: [Swift-devel] wrapper and vdl-int.k updates In-Reply-To: References: <1188958298.26058.12.camel@blabla.mcs.anl.gov> Message-ID: <1189005589.576.0.camel@blabla.mcs.anl.gov> Yes, it would. On Wed, 2007-09-05 at 07:41 +0000, Ben Clifford wrote: > it would be nice if wrapper.sh moved away from having such sensitive > argument handling that it needs very precise quoting (eg the ability to > pass through empty arguments in the middle of the argument list) that > poorly survives going through some execution systems (I think I've seen it > cause trouble going through gram2+condor). From benc at hawaga.org.uk Wed Sep 5 10:21:18 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Wed, 5 Sep 2007 15:21:18 +0000 (GMT) Subject: [Swift-devel] detecting providers Message-ID: How does this list get generated? $ swift first.swift Execution failed: No security context can be found or created for service (provider deef): No 'deef' provider or alias found. Available providers: [gt2ft, gsiftp, condor, pbs, ssh, gt4ft, cobalt, local, dcache, gt4, gsiftp-old, http, gt2, ftp, webdav]. Aliases: local <-> file; pbs <-> pbslocal; gsiftp-old <-> gridftp-old; gsiftp <-> gridftp; cobalt <-> cobaltlocal; gt4 <-> gt3.9.5, gt4.0.2, gt4.0.1, gt4.0.0; -- From hategan at mcs.anl.gov Wed Sep 5 10:24:07 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 05 Sep 2007 10:24:07 -0500 Subject: [Swift-devel] detecting providers In-Reply-To: References: Message-ID: <1189005847.576.2.camel@blabla.mcs.anl.gov> By digging through all cog-provider.properties files on the classpath. Are you getting this too, or are you referring to the error Mike was getting? On Wed, 2007-09-05 at 15:21 +0000, Ben Clifford wrote: > How does this list get generated? > > $ swift first.swift > Execution failed: > No security context can be found or created for service (provider > deef): No 'deef' provider or alias found. Available providers: [gt2ft, > gsiftp, condor, pbs, ssh, gt4ft, cobalt, local, dcache, gt4, gsiftp-old, > http, gt2, ftp, webdav]. Aliases: local <-> file; pbs <-> pbslocal; > gsiftp-old <-> gridftp-old; gsiftp <-> gridftp; cobalt <-> cobaltlocal; > gt4 <-> gt3.9.5, gt4.0.2, gt4.0.1, gt4.0.0; > From benc at hawaga.org.uk Wed Sep 5 10:25:12 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Wed, 5 Sep 2007 15:25:12 +0000 (GMT) Subject: [Swift-devel] detecting providers In-Reply-To: <1189005847.576.2.camel@blabla.mcs.anl.gov> References: <1189005847.576.2.camel@blabla.mcs.anl.gov> Message-ID: I get it attempting to deploy provider-deef with the one line README instruction that I put in before. On Wed, 5 Sep 2007, Mihael Hategan wrote: > By digging through all cog-provider.properties files on the classpath. > > Are you getting this too, or are you referring to the error Mike was > getting? > > On Wed, 2007-09-05 at 15:21 +0000, Ben Clifford wrote: > > How does this list get generated? > > > > $ swift first.swift > > Execution failed: > > No security context can be found or created for service (provider > > deef): No 'deef' provider or alias found. Available providers: [gt2ft, > > gsiftp, condor, pbs, ssh, gt4ft, cobalt, local, dcache, gt4, gsiftp-old, > > http, gt2, ftp, webdav]. Aliases: local <-> file; pbs <-> pbslocal; > > gsiftp-old <-> gridftp-old; gsiftp <-> gridftp; cobalt <-> cobaltlocal; > > gt4 <-> gt3.9.5, gt4.0.2, gt4.0.1, gt4.0.0; > > > > From benc at hawaga.org.uk Wed Sep 5 10:30:14 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Wed, 5 Sep 2007 15:30:14 +0000 (GMT) Subject: [Swift-devel] detecting providers In-Reply-To: <1189005847.576.2.camel@blabla.mcs.anl.gov> References: <1189005847.576.2.camel@blabla.mcs.anl.gov> Message-ID: On Wed, 5 Sep 2007, Mihael Hategan wrote: > Are you getting this too, or are you referring to the error Mike was > getting? If i give the correct path to my deployment, then the error goes away. Now I get successful execution to falkon, but a log warning and it looks like log4j has been overwritten by the provider-deef deploy. The ant dist step of provider-deef gives a BUILD SUCCESFUL message on my machine when told the wrong path - it happily makes that directory and deploys there. That's somewhat fragile behaviour given the intended use of provider-deef. -- From hategan at mcs.anl.gov Wed Sep 5 10:32:23 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 05 Sep 2007 10:32:23 -0500 Subject: [Swift-devel] detecting providers In-Reply-To: References: <1189005847.576.2.camel@blabla.mcs.anl.gov> Message-ID: <1189006343.576.4.camel@blabla.mcs.anl.gov> So something is going on. Check lib and classpath for anything suspicious. On Wed, 2007-09-05 at 15:25 +0000, Ben Clifford wrote: > I get it attempting to deploy provider-deef with the one line README > instruction that I put in before. > > On Wed, 5 Sep 2007, Mihael Hategan wrote: > > > By digging through all cog-provider.properties files on the classpath. > > > > Are you getting this too, or are you referring to the error Mike was > > getting? > > > > On Wed, 2007-09-05 at 15:21 +0000, Ben Clifford wrote: > > > How does this list get generated? > > > > > > $ swift first.swift > > > Execution failed: > > > No security context can be found or created for service (provider > > > deef): No 'deef' provider or alias found. Available providers: [gt2ft, > > > gsiftp, condor, pbs, ssh, gt4ft, cobalt, local, dcache, gt4, gsiftp-old, > > > http, gt2, ftp, webdav]. Aliases: local <-> file; pbs <-> pbslocal; > > > gsiftp-old <-> gridftp-old; gsiftp <-> gridftp; cobalt <-> cobaltlocal; > > > gt4 <-> gt3.9.5, gt4.0.2, gt4.0.1, gt4.0.0; > > > > > > > > From hategan at mcs.anl.gov Wed Sep 5 11:03:14 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 05 Sep 2007 11:03:14 -0500 Subject: [Swift-devel] detecting providers In-Reply-To: References: <1189005847.576.2.camel@blabla.mcs.anl.gov> Message-ID: <1189008194.2298.3.camel@blabla.mcs.anl.gov> On Wed, 2007-09-05 at 15:30 +0000, Ben Clifford wrote: > > On Wed, 5 Sep 2007, Mihael Hategan wrote: > > > Are you getting this too, or are you referring to the error Mike was > > getting? > > If i give the correct path to my deployment, then the error goes away. So you were giving it the wrong path. > > Now I get successful execution to falkon, but a log warning and it looks > like log4j has been overwritten by the provider-deef deploy. > > The ant dist step of provider-deef gives a BUILD SUCCESFUL message on my > machine when told the wrong path There's nothing, besides your intent, that tells this that it was the wrong path. > - it happily makes that directory and > deploys there. That's somewhat fragile behaviour given the intended use of > provider-deef. Also perfectly reasonable behavior in other cases. > From benc at hawaga.org.uk Wed Sep 5 11:06:05 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Wed, 5 Sep 2007 16:06:05 +0000 (GMT) Subject: [Swift-devel] detecting providers In-Reply-To: <1189008194.2298.3.camel@blabla.mcs.anl.gov> References: <1189005847.576.2.camel@blabla.mcs.anl.gov> <1189008194.2298.3.camel@blabla.mcs.anl.gov> Message-ID: On Wed, 5 Sep 2007, Mihael Hategan wrote: > > - it happily makes that directory and > > deploys there. That's somewhat fragile behaviour given the intended use of > > provider-deef. > > Also perfectly reasonable behavior in other cases. provider-deef exists solely to interface falkon to swift. it is never reasonable in normal usage for it to be deployed into a non-swift cog deployment. -- From hategan at mcs.anl.gov Wed Sep 5 11:13:21 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 05 Sep 2007 11:13:21 -0500 Subject: [Swift-devel] detecting providers In-Reply-To: References: <1189005847.576.2.camel@blabla.mcs.anl.gov> <1189008194.2298.3.camel@blabla.mcs.anl.gov> Message-ID: <1189008802.2298.8.camel@blabla.mcs.anl.gov> On Wed, 2007-09-05 at 16:06 +0000, Ben Clifford wrote: > > On Wed, 5 Sep 2007, Mihael Hategan wrote: > > > > - it happily makes that directory and > > > deploys there. That's somewhat fragile behaviour given the intended use of > > > provider-deef. > > > > Also perfectly reasonable behavior in other cases. > > provider-deef exists solely to interface falkon to swift. it is never > reasonable in normal usage for it to be deployed into a non-swift cog > deployment. > Add a check in the build file then. From hategan at mcs.anl.gov Wed Sep 5 12:28:40 2007 From: hategan at mcs.anl.gov (Mihael Hategan) Date: Wed, 05 Sep 2007 12:28:40 -0500 Subject: [Swift-devel] detecting providers In-Reply-To: <1189008802.2298.8.camel@blabla.mcs.anl.gov> References: <1189005847.576.2.camel@blabla.mcs.anl.gov> <1189008194.2298.3.camel@blabla.mcs.anl.gov> <1189008802.2298.8.camel@blabla.mcs.anl.gov> Message-ID: <1189013320.13350.0.camel@blabla.mcs.anl.gov> On Wed, 2007-09-05 at 11:13 -0500, Mihael Hategan wrote: > On Wed, 2007-09-05 at 16:06 +0000, Ben Clifford wrote: > > > > On Wed, 5 Sep 2007, Mihael Hategan wrote: > > > > > > - it happily makes that directory and > > > > deploys there. That's somewhat fragile behaviour given the intended use of > > > > provider-deef. > > > > > > Also perfectly reasonable behavior in other cases. > > > > provider-deef exists solely to interface falkon to swift. it is never > > reasonable in normal usage for it to be deployed into a non-swift cog > > deployment. > > > > Add a check in the build file then. I added a warning to provider-deef/build.xml that gets printed and pauses the build if there is no ${dist.dir}/bin/swift. > > _______________________________________________ > Swift-devel mailing list > Swift-devel at ci.uchicago.edu > http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel > From benc at hawaga.org.uk Wed Sep 5 12:51:35 2007 From: benc at hawaga.org.uk (Ben Clifford) Date: Wed, 5 Sep 2007 17:51:35 +0000 (GMT) Subject: [Swift-devel] Re: latest Falkon code is in SVN! In-Reply-To: <46D7FE11.7070204@cs.uchicago.edu> References: <46D4970E.4000809@cs.uchicago.edu> <46D4A46C.6070806@mcs.anl.gov> <46D4AB05.9070900@cs.uchicago.edu> <46D7FE11.7070204@cs.uchicago.edu> Message-ID: On Fri, 31 Aug 2007, Ioan Raicu wrote: > Right, bu default, all the scripts are without security. To enable security, > one would have to modify 3 scripts (the service script -- remove -nosec > option, the worker script -- replace http with https, and the client script -- > replace http with https), and update the etc/client-security-config.xml on the > worker and client accordingly with the relevant security parameters. It is > pretty straight forward, but I haven't got the chance to document it yet. I made this change: --- worker/etc/client-security-config.xml (revision 1191) +++ worker/etc/client-security-config.xml (working copy) @@ -1,8 +1,8 @@ - - + + > > - > - > + > + >