Thanks, you're the greatest! I think that the save attribute is necessary, since we need to --connect-id flag to not be saved between sessions - and to truly be random. This is mandatory for some of our systems.
Alan > -----Original Message----- > From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com] > Sent: Monday, January 11, 2010 12:05 PM > To: Moreland, Kenneth > Cc: Rick Angelini; Scott, W Alan; ParaView > Subject: Re: [Paraview] Paraview 3.6.x connection definition files > > Folks, > > I've committed a fix for this. The updating of the user's > servers.pvsc file was totally unnecessary (there was code > elsewhere that handled BUG #5487). However the user > selections for only those <Option /> elements that have the > "save" attribute set to true are preserved across sessions. > > Refer to > http://www.paraview.org/Wiki/ParaView:Server_Configuration#Cas > e_Eight:_Starting_server_using_ssh > > for details on the "save" attribute. I am wondering if that's > even needed and we can always save all options i.e. assume > "save" is true by default. What do you think? > > Utkarsh > > On Mon, Nov 9, 2009 at 10:45 AM, Moreland, Kenneth > <kmo...@sandia.gov> wrote: > > I've submitted a bug on this issue: > > > > http://www.paraview.org/Bug/view.php?id=9866 > > > > Please take a look at it and see if it and the suggested solution > > addresses the problem. > > > > -Ken > > > > > > On 11/5/09 12:25 PM, "Rick Angelini" <an...@arl.army.mil> wrote: > > > > Alan - I think that you do want to allow the user to create > their own > > connection definitions files, so you need to maintain the > > functionality of item #2 & item #4. Maybe there's a check > to make sure > > that the user-defined connection is not the same name as > > system-defined connection (thus won't overwrite?). Or, better yet, > > differentiate the connections with something like > "User:BigRedCluster" > > and "Global:BigRedCluster" depending on where the > definition was read from? > > > > Scott, W Alan wrote: > >> Seems to me that we really want ParaView to do the following: > >> * Read server connection information from a system level file. > >> * Read server connection information from a user level file. This > >> information shall not override anything read in from the > system level > >> file. (Do we even need this file?) > >> * Read in the user's default connection information from a > user level > >> file. > >> * Allow the user to edit the server information. (Do we even need > >> this > >> step?) > >> * When ParaView finishes, write out the current server information > >> (from the system level and the user level) into a user level file. > >> (Do we even need this?) > >> * Write preferences into a preferences file. > >> Thoughts? > >> Alan > >> > >> > >> > >> > --------------------------------------------------------------------- > >> --- > >> *From:* Moreland, Kenneth > >> *Sent:* Thursday, November 05, 2009 8:02 AM > >> *To:* Rick Angelini; Scott, W Alan > >> *Cc:* ParaView > >> *Subject:* Re: [Paraview] Paraview 3.6.x connection definition > >> files > >> > >> It sounds like the major problem is that ParaView is taking the > >> server connection configurations from the system files and > >> writing > >> them in the servers.pvsc configuration file the first time it > >> encounters them, where they forever override any changes to the > >> system files. I believe this behavior was introduced > to save the > >> user's last entries for the parameters as the default for the > >> next > >> invocation (bug #5487). > >> > >> This is an important feature, but perhaps this is not the best > >> way > >> to implement it. Perhaps ParaView should be saving the server > >> connection argument parameters in the regular settings > key/value > >> file. That way you could leave the system server > settings in the > >> system files and nothing would override them. Does that sound > >> like > >> the right thing? > >> > >> -Ken > >> > >> > >> On 11/5/09 6:00 AM, "Rick Angelini" <an...@arl.army.mil> wrote: > >> > >> Alan, yes, you've demonstrated the problem I found > with the > >> pvsc > >> files. It's a difficult problem: > >> > >> Ideally, we want to provide > >> 1. Global server connection definitions > >> 2. User-defined server connection definitions > >> 3. the ability save persistent information > (username, remote > >> shell > >> executable, ProjectID, etc, etc) as defined by the pvsc > >> definition > >> 4. Update the global connection definition and have it > >> override any > >> previous definition > >> > >> I think that it's a slightly larger issue than > just managing > >> variables > >> that may exist between the user copy of the definition and > >> the > >> global > >> copy - we need to provide the capability to drop > in a totally > >> new global > >> pvsc file and have it override anything that may have been > >> saved > >> locally. For instance, we just switched our queuing system > >> from LSF to > >> PBS and the entire pvsc file changed. Ideally, > when the new > >> global > >> server definition was dropped into the place, the user copy > >> for that > >> server would be totally replaced by the new definition. > >> > >> Scott, W Alan wrote: > >> > > >> > Rick, > >> > It sure looks wrong to me. I did as you said - > >> > * Deleted my local .config/ParaView/servers.pvsc file. > >> > * Ran ParaView, connected to a remote server, then closed > >> ParaView. > >> > - This read in my default_servers.pvsc file > >> > - Wrote out a new local > .config/ParaView/servers.pvsc file. > >> > * I then changed one of the options to be wrong in the > >> users > >> > servers.pvsc file. (I used max NODES, which should > >> obviously > >> be from > >> > the system default_servers.pvsc). This information was > >> still > >> correct > >> > in the default_server.pvsc file. > >> > * Upon rerunning ParaView, the wrong information > was picked > >> up from > >> > the servers.pvsc file. > >> > > >> > > >> > What would be the correct behavior? We want to > always use > >> the > >> default > >> > value from the user's servers.pvsc file, but we > want to use > >> all of the > >> > other variables from the default_servers.pvsc > file. Right? > >> > > >> > Alan > >> > > >> > > -----Original Message----- > >> > > From: Rick Angelini [mailto:an...@arl.army.mil] > >> > > Sent: Monday, November 02, 2009 8:36 AM > >> > > To: Scott, W Alan > >> > > Cc: ParaView; Moreland, Kenneth > >> > > Subject: Re: [Paraview] Paraview 3.6.x connection > >> definition files > >> > > > >> > > You're correct, the FIRST place it looks is for the > >> system > >> default. > >> > > However, the SECOND place it looks is the user's area, > >> which > >> > > OVERRIDES > >> > > the systems default, as best as I can tell. If HostA is > >> defined in > >> > > the default_servers.pvsc, the first time it > gets loaded > >> it > >> is then > >> > > saved into the user's local servers.pvsc file. > I need to > >> do > >> more > >> > > testing, but it looks like even if the > default.pvsc file > >> is > >> > > updated, the original definition that was saved off in > >> the > >> > > users area is used. > >> > > > >> > > > >> > > Scott, W Alan wrote: > >> > > > Rick, > >> > > > To be honest, I didn't even realize that there was a > >> > > servers.pvsc in > >> > > > the home directory. The first place that > ParaView looks > >> for GUI > >> > > > connection information is in your Paraview > install area. > >> > > On our LANS, > >> > > > this is > .../3.6.2/Linux-x86_64/lib/paraview-3.6 (which > >> is > >> really > >> > > > wherever_paraviews_root_is/lib/paraview-3.6) I have a > >> > > > default_servers.pvsc in there. > >> > > > > >> > > > For standalone Linux installs, I put this > >> > > default_servers.pvsc in the > >> > > > same place .../local_paraview_base/lib/paraview-3.6. > >> > > > > >> > > > In XP it goes in the ParaView install directory - > >> c:/Program > >> > > > Files/ParaView 3.6.2/bin. > >> > > > > >> > > > Give me a call if you want to discuss. > >> > > > > >> > > > Alan > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > ------ Forwarded Message > >> > > > *From: *Rick Angelini <an...@arl.army.mil> > >> > > > *Date: *Fri, 23 Oct 2009 10:55:10 -0600 > >> > > > *To: *<ParaView@paraview.org> > >> > > > *Subject: *[Paraview] Paraview 3.6.x connection > >> definition files > >> > > > > >> > > > I have questions regarding the use of connection > >> > > definition files. > >> > > > > >> > > > I have created numerous connection > definition files for > >> various > >> > > > clusters > >> > > > and compute systems that we have here. Up until > >> > > now, I've been > >> > > > distributing those pvsc files through a common > >> > > directory that all > >> > > > of my > >> > > > users have access to. They manually load the pvsc > >> > > files into their > >> > > > session, and those server definitions get > automatically > >> > > saved into > >> > > > $HOME/.config/ParaView/servers.pvsc. The > >> > > connection definition > >> > > > files work great and are a huge time saver > for Paraview > >> users - > >> > > > particularly in an environment where we need to > >> > > establish SSH tunnels, > >> > > > modify ports and connection IDs, etc. > >> > > > > >> > > > The problem lies in what happens when I want > to change > >> > > one or more of > >> > > > those pvsc files (presumably to incorporate a change > >> > > that will improve > >> > > > functionality, performance, etc 8-) I update the > >> > > pvsc file in the > >> > > > common directory, and then I need to notify all of my > >> > > Paraview users > >> > > > that there's an update to the PVSC files and > that they > >> need to > >> > > > delete/replace their existing definition > with a new one. > >> This > >> > > > scenario > >> > > > is awkward and requires some effort on the > users' part > >> > > - it would be > >> > > > nice if there were a more automatic solution. > >> > > > > >> > > > So, I've been looking at using a default_servers.pvsc > >> > > file which in > >> > > > theory is a great idea. All users would have access > >> > > to a common pvsc > >> > > > file that I can control and update as > necessary, with > >> no > >> updates > >> > > > required by the user. Well, unfortunately, it doesn't > >> > > seem to really > >> > > > work that way. The default_servers.pvsc file is read > >> > > in the first > >> > > > time ParaView is loaded, and then those server > >> > > definitions are saved > >> > > > back to the $HOME/.config/ParaView directory. The > >> servers are > >> > > > presumably saved off to preserve some of the > >> > > information as defined in > >> > > > the PVSC file - I have numerous fields (UserID, > >> ProjectID, SSH > >> > > > executable labeled with "save=true" so that that > >> information is > >> > > > carried > >> > > > over between sessions. > >> > > > > >> > > > This is where we start to run into problems. > >> > > According to the > >> > > > WIKI, > >> > > > the last server definition loaded take > precedence, so > >> if > >> I make > >> > > > changes > >> > > > to the "default_servers.pvsc" file, it gets loaded > >> prior to > >> > > > "$HOME/.config/ParaView/servers.pvsc". Unless I'm > >> missing > >> > > > something, > >> > > > once the server definitions are initialized the first > >> > > time they are > >> > > > recognized and saved off to the user's .config > >> > > directory, the default > >> > > > servers will never have precedence, even if I > >> change/update the > >> > > > contents. Unless the ServerName is changed for each > >> > > subsequent update > >> > > > of a particular server, any updated server in the > >> > > default servers file > >> > > > won't be loaded. Am I on the right track here - have > >> > > I missed or > >> > > > assumed something that I shouldn't have? It looks > >> > > like all of the > >> > > > hooks are *almost* there to manage the server > >> definitions > >> ..... > >> > > > > >> > > > Also, using 3.6.1, I went through the process of > >> created a > >> > > > default_servers.pvsc, having those servers > >> > > automatically loaded in my > >> > > > ParaView session, and then have them saved > off into a > >> local > >> > > > servers.pvsc > >> > > > file. However, during the next Paraview session, the > >> > > definitions > >> > > > don't > >> > > > work properly - it seems as those the only the last > >> item > >> in an > >> > > > enumerated list are available through the GUI, and in > >> > > general it just > >> > > > doesn't work correctly. If those same server > >> > > definitions are loaded > >> > > > manually by the user and saved locally, they work > >> > > fine. So, there's > >> > > > apparently an issue related to the use of the > >> > > default_servers.pvsc and > >> > > > how those definitions are saved out to the user's > >> > > server.pvsc file. > >> > > > > >> > > > > >> > > > > >> > > > _______________________________________________ > >> > > > Powered by www.kitware.com > >> > > > > >> > > > Visit other Kitware open-source projects at > >> > > > http://www.kitware.com/opensource/opensource.html > >> > > > > >> > > > Please keep messages on-topic and check the ParaView > >> Wiki > >> at: > >> > > > http://paraview.org/Wiki/ParaView > >> > > > > >> > > > Follow this link to subscribe/unsubscribe: > >> > > > http://www.paraview.org/mailman/listinfo/paraview > >> > > > > >> > > > > >> > > > > >> > > > ------ End of Forwarded Message > >> > > > > >> > > > >> > > > >> > > >> > >> > >> > >> > >> **** Kenneth Moreland > >> *** Sandia National Laboratories > >> *********** > >> *** *** *** email: kmo...@sandia.gov > >> ** *** ** phone: (505) 844-8919 > >> *** web: http://www.cs.unm.edu/~kmorel > >> <http://www.cs.unm.edu/%7Ekmorel> > >> > > > > > > > > > > **** Kenneth Moreland > > *** Sandia National Laboratories > > *********** > > *** *** *** email: kmo...@sandia.gov > > ** *** ** phone: (505) 844-8919 > > *** web: http://www.cs.unm.edu/~kmorel > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the ParaView Wiki at: > > http://paraview.org/Wiki/ParaView > > > > Follow this link to subscribe/unsubscribe: > > http://www.paraview.org/mailman/listinfo/paraview > > > > > > _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview