[Paraview] Paraview 3.6.x connection definition files
Rick Angelini
rick.angelini at us.army.mil
Tue Mar 23 14:59:18 EDT 2010
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