That seems to be doing the trick. Thanks for the quick fix.
Utkarsh Ayachit wrote:
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.angel...@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.ayac...@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.angel...@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.ayac...@kitware.com> wrote:
Ah...interesting thought. I'll take a look.
On Fri, Mar 19, 2010 at 11:41 AM, Rick Angelini
<rick.angel...@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
<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
_______________________________________________
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
