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

[Dave Wootton <dwootton@xxxxxxxxxx>]

Yes, option 2 for storing the selection
of which attributes to display seems like the preferable option to me since
the attribute set is a characteristic of the resource manager not of the
application specified in the run configuration. This way a user will see
the same set of attributes for a resource manager regardless what application/run
configuration is selected. This might be confusing in that changing the
set of  attributes in one run configuration changes what's seen in
another run configuration, but I'm not sure that seeing different sets
of attributes for a specific resource manager in different run configurations
is any less confusing.
Dave

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

---

Yes, I agree with values being specific to the run
configuration (that's what I did with PBS too).  But that wasn't my
question, exactly. But if I can deduce your meaning, you are saying that
the attribute set is specific to an RM.  So if there is a control
which allows the user to choose which of those attributes to display, that
should be valid for the RM, whatever Launch Tab it is used with.  In
other words, you think (2) is the correct mapping.

I agree that this probably makes more sense, except that the user may be
surprised by the fact that the Launch Tab is allowing her to reconfigure
something which is going to affect other Launch Tabs using the same RM.
 

An early version of the PBS RM did not provide this selection capability
through the Launch Tab, but rather in the RM configuration wizard; while
less confusing, it meant that every time the user wishes to modify exactly
which of the available advanced attributes get displayed, the RM must be
shut down, then restarted.



----- Dave Wootton <dwootton@xxxxxxxxxx> wrote:
> 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
> 
> 

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