Re: [ptp-dev] resource_manager.xsd version 5 questions/comments

[Dave Wootton <dwootton@xxxxxxxxxx>]

Al
If I understand correctly what you're
asking, the XML specification for a resource manager controls what set
of attributes get displayed in a run configuration when that resource manager
is the selected resource manager for that run configuration. So the user
can see a different set of attributes in the run configuration if he switches
between selected resource managers in that run configuration.

The value for a specific attribute in
a run configuration should be associated with only that run configuration.
If I change the value of an attribute in one run configuration, it should
not affect the value of that attribute in any other run configuration.
So If I change between selected resource managers in a specific run configuration,
where those two resource managers both use the same attribute, I would
expect that value to remain constant as I switch between resource managers
unless the user modifies the value himself.

Given that, my opinion is that the attribute
values are persistent within the run configuration.
Dave

From:	"Albert L. Rossi" <arossi@xxxxxxxxxxxxx>
To:	Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
Date:	01/27/2011 09:46 AM
Subject:	Re: [ptp-dev] resource_manager.xsd version 5 questions/comments
Sent by:	ptp-dev-bounces@xxxxxxxxxxx

---

So here is another question which I've been going
back and forth on.

In essence we have 3 "configurations".

1.  This resource manager data configuration which defines the RM
type.
2.  An actual instance [what is currently the resource manager configuration
interface, used to persist the runtime info]
3.  A run or launch configuration which persists the filled in values.

It is my idea that the user should have control over which of the valid
advanced attributes get displayed if that makes sense for an RM (such as
PBS).  However, it is not clear whether this choice should be persisted
in (2) or (3).

If we persist it with (2), this means that a resource manager which is
shared between two different Launch Tabs will display the same attributes,
and if the user changes the choice in one Launch Tab, it will also change
for the other Launch Tab.

If we persist it with (3), this would mean that two different RMs swapped
in and out of a single Launch Tab will adopt the Launch Tab configuration
(or the valid subset thereof) for which attributes to display; the user
changes this setting with respect to the Launch Tab, not the RM.

Which of these two options makes more sense from the user's perspective?

Al


----- Albert L. Rossi <arossi@xxxxxxxxxxxxx> wrote:
> Dave,
> 
> just realized I read your first question incorrectly.  I now
see what you are asking: if you use the same Launch Tab (run configuration
or launch configuration) but swap different resource managers in and out,
what happens?  My idea was indeed to do as you say (this is what PBS
does):  the valid attributes come from the resource manager configuration,
their values from the launch configuration, so if there are attributes
which are not valid for a given RM, these will not appear even though they
may have been for the previous RM inside that run configuration (and their
values persisted).  The next time that previous RM is swapped back
in, those values should reappear.
> 
> 
> Al
> 
> 
> 
> ----- Albert L. Rossi <arossi@xxxxxxxxxxxxx> wrote:
> > Dave, 
> > 
> > 1)  I'm not quite sure how you're thinking this should work.
 It seems to me that there should indeed be an attribute on the job-attribute
marking it for OS.  The RM implementation needs to be agnostic as
to what it really is (LL, PE, etc.).  If there is a general filtering
mechanism, this can be implemented, I think, without too much difficulty.
 For dynamic attributes, I just assumed that whatever command you
configure to get them will give you the correct ones.
> > 
> > 2)  This is one-size-fits all.  It's basically saying
to the user:  here's an editor; take a customized script you've written,
or write one, and that's what we'll give to the launch command.  What
you see is what you get.
> > 
> > 3)  I see no problem adding one or more enumeration types
that correspond to those variants.  This widget I envisaged as being
a double widget:  a text box followed by a push button.  But
the dialog that comes up could be different based on the subtype.
> > 
> > Thanks, Al
> > 
> > ----- Dave Wootton <dwootton@xxxxxxxxxx> wrote:
> > > Al
> > > I took a look at version 5 of your schema and I think it
generally does 
> > > what I need. Once there is a workable implementation I'll
have to 
> > > experiment a bit. I do have a few comments/questions
> > > 
> > > 1) I was looking at the definition of the argslist element
and the 
> > > reference to dynamic attributes. I'm not quite sure hos
this is supposed 
> > > to work, but what occurred to me at this point was that
I have a run 
> > > configuration that has a set of attributes with values stored
in it, where 
> > > I may have used that same run configuration with several
different 
> > > resource managers that accept only a subset of the attributes
that are in 
> > > the run configuration. For instance I may use the same run
configuration 
> > > to run PE applications on both AIX and Linux, where some
PE options may 
> > > not be valid on Linux or AIX. Do you anticipate that the
resource manager 
> > > will filter the attributes in a run configuration so that
only the set of 
> > > valid attributes and their values is displayed in the run
configuration 
> > > and passed to the application in the run command? I'm thinking
the set of 
> > > allowable attributes that would be displayed and passed
to the application 
> > > would be what's defined in the XML file for that configuration
and the 
> > > rest of the attributes in the run configuration would be
ignored.
> > > 
> > > 2) In the launch-tab element there's an advancedModeEnabled
element that 
> > > allows the user to edit/create a script file. What's expected
to be in 
> > > that script file and how does that get passed in the run
command. Is this 
> > > expected to be the exact command(s) used to invoke the application
or is 
> > > it something like a .rc file with a bunch of environment
variable 
> > > settings? I think a script with the exact commands would
be acceptable 
> > > since this is 'advanced mode', but not sure that's what
you intended.
> > > 
> > > 3) I was looking at the widget element. In there, there
is an enumeration 
> > > for browseButton. In my PE implementation, I have three
different 
> > > variations of a selector dialog, browse for an existing
directory, where 
> > > only directories can be selected. browse for existing file
which accepts 
> > > only file selections and browse for file where the user
may type in the 
> > > name of a new file once he navigates to the desired directory.
Do we want 
> > > that level of specification in the schema?
> > > 
> > > Dave
> > _______________________________________________
> > ptp-dev mailing list
> > ptp-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ptp-dev
> > 
> 

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev