I've ensured that when "random" is specified as the default value for any option, which is the case with --connect-id, then the value is always regenerated, so this will be a non-issue. Also you can always add save="false" attribute, if needed -- but not necessary in this case.
Utkarsh On Mon, Jan 11, 2010 at 8:38 PM, Scott, W Alan <wasc...@sandia.gov> wrote: > Am I missing something, or would we also save the --connect-id flag between > sessions? This needs to be new, and random, each and every time we run. > > This was the reason that the save option was put into Paraview - so we > wouldn't save the --connect-id variable. > > Alan > >> -----Original Message----- >> From: Moreland, Kenneth >> Sent: Monday, January 11, 2010 1:52 PM >> To: Scott, W Alan; Utkarsh Ayachit >> Cc: Rick Angelini; ParaView >> Subject: Re: [Paraview] Paraview 3.6.x connection definition files >> >> Utkarsh, >> >> Is there a reason why we should not save all options as >> opposed to just those with the "save" attribute? I cannot >> think of a good use case to not save an option, and even if >> there is a good use case wouldn't it be rare enough to >> justify saving by default and having an attribute to turn off >> saving? Furthermore, until you made that change the behavior >> has been to save all of the options, and to my knowledge no >> one has complained about that. >> >> -Ken >> >> >> On 1/11/10 12:11 PM, "Scott, W Alan" <wasc...@sandia.gov> wrote: >> >> > 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 >> >>> >> >>> >> >> >> >> >> >> >> **** 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