 |
 |
On Fri, 2012-09-14 at 12:37 -0700, McCormick, Jeremy I. wrote: > The problem with a database, as I see it, is that the user either has > to run this themselves on their local machine, which is an extra > amount of installation and setup, OR there has to be a shared instance > that hps-java accesses, especially for jobs run on batch farms or the > grid. (The database also has to be kept up to date, which is more > complicated than the current method of 'cvs up' to get new text > files.) Either one of these working methods could cause problems with > how we currently do things. For one, many batch systems are not that > friendly when it comes to connecting out to databases unless this is > preconfigured by their admins to allow it. And having users run their > own MySQL database just strikes me as an unnecessary headache. We > already have enough troubles getting people to install and run the > software on their own machines, and this would add another hurdle that > frankly isn't necessary right now. Hi Jeremy, clearly it is up to HPS whether you want to use the database or not, if you are happy with your current solution that is fine, we just wanted to make sure you were aware of the alternatives. It certainly would not make sense for users to set up their own database. We have a mysql database set up at SLAC which can be accessed globally and which already has table space configured for HPS. This is the same database scheme which has been used successfully by Fermi and EXO to run jobs worldwide. Of course your usage pattern may be different and run into the kind of remote firewall issues you mention. Tony ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1