[Paraview] Paraview 3.6.x connection definition files
Utkarsh Ayachit
utkarsh.ayachit at kitware.com
Tue Mar 23 15:50:14 EDT 2010
Ah, ok. I've committed a fix.
/cvsroot/ParaView3/ParaView3/Qt/Components/pqSimpleServerStartup.cxx,v
<-- Qt/Components/pqSimpleServerStartup.cxx
new revision: 1.37; previous revision: 1.36
Utkarsh
On Tue, Mar 23, 2010 at 2:59 PM, Rick Angelini
<rick.angelini at us.army.mil> wrote:
> I'm concerned that this is not a unique identifier. For a variety of
> reasons, we have to do a lot of reverse connections, SSH tunnels, etc, and
> ALL of my connection definition files use a resource of "csrc%3A\127.0.0.1"
>
> Utkarsh Ayachit wrote:
>>
>> FYI, I also fixed the typo in the name SERVER_STARUP is now called
>> SERVER_STARTUP.
>>
>> Utkarsh
>>
>> On Tue, Mar 23, 2010 at 2:33 PM, Utkarsh Ayachit
>> <utkarsh.ayachit at kitware.com> wrote:
>> > That should still work just fine -- Qt ensures that the "key" is
>> > transformed to a valid format before putting it in the file. Is it
>> > not working for you or are you just skeptical that those funny looking
>> > keys may not work?
>> >
>> > Utkarsh
>> >
>> > On Tue, Mar 23, 2010 at 12:44 PM, Rick Angelini
>> > <rick.angelini at us.army.mil> wrote:
>> >> I'm thinking that this change is *almost* correct, but maybe not quite?
>> >> It
>> >> looks like you appended the server resource string rather than the
>> >> server
>> >> name? I'm not sure that the resource string works well in this
>> >> instance????
>> >>
>> >> csrc%3A\127.0.0.1.PROJECTNUM=XYZ123ABC
>> >> csrc%3A\127.0.0.1.PV_CONNECT_ID=28594
>> >> csrc%3A\127.0.0.1.USERNAME=joeuser
>> >> csrc%3A\127.0.0.1.SERVERNAME=hostname.mil
>> >> csrc%3A\127.0.0.1.NUMPROC=2
>> >> csrc%3A\127.0.0.1.SSHLOC=/usr/local/bin/ssh
>> >> csrc%3A\127.0.0.1.PV_SERVER_PORT=22884
>> >> csrc%3A\127.0.0.1.QUEUE=debug
>> >> csrc%3A\127.0.0.1.SERVER_PORT=6879
>> >> csrc%3A\127.0.0.1.VERSION=3.6.2
>> >> csrc%3A\127.0.0.1.PTILE=1
>> >> csrc%3A\127.0.0.1.WALLTIME=5
>> >>
>> >>
>> >>
>> >>
>> >> Utkarsh Ayachit wrote:
>> >>>
>> >>> Rick,
>> >>>
>> >>> I've committed a fix for this. Feel free to give it a try.
>> >>>
>> >>> Utkarsh
>> >>>
>> >>> On Fri, Mar 19, 2010 at 11:57 AM, Utkarsh Ayachit
>> >>> <utkarsh.ayachit at kitware.com> wrote:
>> >>> > Ah...interesting thought. I'll take a look.
>> >>> >
>> >>> > On Fri, Mar 19, 2010 at 11:41 AM, Rick Angelini
>> >>> > <rick.angelini at us.army.mil> wrote:
>> >>> >> I've run into a situation where things are not yet being handled
>> >>> >> correctly
>> >>> >> with this issue. I'm currently testing with 3.7.x assuming
>> >>> >> that's
>> >>> >> the
>> >>> >> where the work is going on for the next release. The original
>> >>> >> issue
>> >>> >> can be
>> >>> >> found here:
>> >>> >>
>> >>> >> http://www.paraview.org/Bug/view.php?id=9866#c18827
>> >>> >>
>> >>> >>
>> >>> >> As stated in the issue resolution, the saved values are now being
>> >>> >> stored in
>> >>> >> the users .ini file, but they are not unique for each server.
>> >>> >> That
>> >>> >> is,
>> >>> >> it appears to be creating "global variables" rather than saving
>> >>> >> off
>> >>> >> variables per server. So, I have something that looks like this
>> >>> >> in
>> >>> >> my
>> >>> >> .ini file:
>> >>> >>
>> >>> >> [SERVER_STARUP]
>> >>> >> SSHLOC=/usr/local/bin/ssh
>> >>> >> LOGINNODE=login-node1
>> >>> >> USERNAME=user
>> >>> >> PROJECTNUM=ABC123Project
>> >>> >> PV_CONNECT_ID=13829
>> >>> >> NODES=2
>> >>> >> QUEUE=debug
>> >>> >> SERVER_PORT=55876
>> >>> >> WALLTIME=60
>> >>> >> VERSION=3.7.0
>> >>> >>
>> >>> >> If I now load up a different server which happens to use the same
>> >>> >> variable
>> >>> >> names, these automatically get dumped into the connection
>> >>> >> definition
>> >>> >> file,
>> >>> >> which is OK assuming that you have the same USERNAME, PROJECTNUM,
>> >>> >> etc
>> >>> >> across
>> >>> >> all systems, which is not the case. So, I have multiple
>> >>> >> connection
>> >>> >> definition files pointing to multiple machines with different
>> >>> >> usernames
>> >>> >> and
>> >>> >> ProjectIDs, and by default I'm getting the values from the previous
>> >>> >> session
>> >>> >> rather than the values from the previous session for that
>> >>> >> particular
>> >>> >> server.
>> >>> >> I'm wondering if the best way to save these variables is
>> >>> >> something
>> >>> >> more
>> >>> >> like this:
>> >>> >>
>> >>> >> hostname1.USERNAME=jimuser
>> >>> >> hostname1.PROJECTNUM=ABC123Project
>> >>> >> hostname2.USERNAME=joeuser
>> >>> >> hostname2.PROJECTNUM=XYZ789Project
>> >>> >>
>> >>> >> Where "hostname" is the Server name from the .pvsc file.
>> >>> >>
>> >>> >>
>> >>> >> Utkarsh Ayachit wrote:
>> >>> >>>
>> >>> >>> 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
>> >>> >>> <wascott at 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" <wascott at 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.ayachit at 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
>> >>> >>> >> >> <kmorel at 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" <angel at 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"
>> >>> >>> >> <angel at 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:angel at 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
>> >>>
>> >>
>> >
>>
>
More information about the ParaView
mailing list