[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] Updated Resource Manager Schema
|
Let's think about this in general terms.
If there are any attributes that are dynamically defined -- that is, their names are not known until runtime -- then the best we can do is hold them apart in a data structure that is distinct from the static attributes, and when we construct the UI, we just provide for adding these. I'm not sure how else we could add this to the control except as a <group> which we would just under-specify, say as containing <dynamic-attributes>. The implementation will just take the special data structure in that case and add the attributes one by one to the group according to a predefined attribute-type-to-widget mapping. If you prefer, we could also maintain the current advanced setup for openMPI and use an editable table with checkboxes. (This type of widget probably should also be added to our enumeration of widget types; it would be understood that such a widget is populated from a list.)
So what we need to add to the schema are two elements: in the UI part, if the <group> has as its single element <dynamic-attributes>, then the implementation puts them there; and we could add an attribute, "useSingleTable" or whatever the appropriate name might be, to indicate these should be built as a single table widget instead of each attribute being mapped to a particular widget type.
Does that sound like it will work?
----- Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
> Yes, it sounds like the launch configuration tab should be handled via a separate configuration file (or section of the rm config file). Maybe we still need to allow a custom tab to be built in Java to handle unusual cases?
>
> The problem with your scheme below (I think) is it assumes that you know what the options/parameters are beforehand. However, in the OpenMPI case there are a whole bunch of options that are installation dependent. All I know is that they have to be prefixed with -mca, but I don't know the option name until I query the runtime. We could populate the property map with the parameter names, but there is now way to explicitly refer to them as their names are unknown until the on-start-up command is run.
>
> Greg
>
> On Jan 19, 2011, at 11:47 AM, Albert L. Rossi wrote:
>
> > More thoughts: both the options and the values probably should be part of the Launch Configuration, not the RM Config per se.
> >
> > Also, we currently cache RMs, so the construction of the RM need only take place once.
> >
> > If an RM is shared by more than one Launch Tab, the values will just get swapped in and out for the properties as the view switches (cf. PBS currently).
> >
> > I'm wondering if we should now switch this discussion to comments on the Wiki?
> >
> > ----- Albert L. Rossi <arossi@xxxxxxxxxxxxx> wrote:
> >> Actually, I think I fused two things here. There is the RM and then there is the LaunchTab. The RM per se has no createControl (it's not a ViewPart). So basically the property map / environment update (5) is the last thing that happens, except the part regarding the Launch configuration doesn't take place there. It takes place when the Launch Tab is constructed. The tab may actually wish to maintain is own subset of properties.
> >>
> >> ----- Albert L. Rossi <arossi@xxxxxxxxxxxxx> wrote:
> >>> Hi Greg,
> >>>
> >>> I haven't thought through completely the exact sequence of actions, but I would assume something like this will take place:
> >>>
> >>> 1. RM is constructed
> >>> 2. RM data object is unmarshalled from configuration
> >>> 3. Environment map is built from properties, defined attributes, parsers, perhaps command names too (not sure if we need that). Some of these properties will have NULL values initially.
> >>> 4. on-start-up and retrieve-dynamic-attributes are optionally run. It is assumed that the commands issued will side-effect the environment appropriately.
> >>> 5. The environment is updated against the options for display that may have already been persisted a Service/RM Configuration (runtime instance), and the last values associated with them in a Launch Configuration for an already created tab.
> >>> 5. createControl is called. This should then build the UI part as described in the configuration using the environment properties.
> >>>
> >>> The <widget> element has specified two children, <content>, which can reference an attribute value or predefined list of values, and <saveValueTo>, which should be a property name. When the widget is created, its content is thus provided by dereferencing any and all tags in it. Usually these will simply correspond to some property, but if the widget is read-only (such as that command line in the openMPI UI), then it could be a string like: "foo -v ${v} /path -x ${x} ${myOptions}", etc. The save method would store the values in the properties map.
> >>>
> >>> The property map (the environment) actually may need an special inner class object for its value saying where (if at all) to persist the value (which configuration).
> >>>
> >>> My own question is whether this represents too much latency between creation and the display of the UI tab. If it does, we may either need to alert the user with a ProgressBar/message or see if we can't do an initially empty view which then is refreshed.
> >>>
> >>> Insofar as the ability to control the display, I think that should be built in to the tab the way it is in PBS. Instead of pulling up templates, the user can click a button which will display a simple list of attributes with a checkbox. Unchecking that attribute eliminates them from the display.
> >>>
> >>> Al
> >>> ----- Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
> >>>> Al,
> >>>>
> >>>> No, nothing that complicated. I think you've clarified how it works for me.
> >>>>
> >>>> However, I have another question. The "on-start-up" command will also generate a (large) list of arbitrary attributes and default values. These attributes must then be used to create an attribute list with the default values in editable fields. How would this be achieved?
> >>>>
> >>>> Greg
> >>>>
> >>>> On Jan 19, 2011, at 8:50 AM, Albert L. Rossi wrote:
> >>>>
> >>>>> Hi Greg,
> >>>>>
> >>>>> To answer your second question, yes the order of the commands is the order of execution. If you think an explicit order attribute is better, we can add that.
> >>>>>
> >>>>> I'm not sure I follow the first part, though. Are you saying that the way we obtain version information could vary depending on the version itself, so that a single tokenization may not work? In that is the case, then what we really need is for the command sequence to be generalized so that we can express both <and> and <or>; and startup would then try command A, and if that fails, command B, etc; each of those having the appropriate parser to find the version information from the command output.
> >>>>>
> >>>>> Once the version information is set (giving a value to the ${version} property), then subsequent command definitions can then proceed to do as I have currently provided for:
> >>>>>
> >>>>> <command>
> >>>>> <arg>
> >>>>> ...
> >>>>> <stream-parser stdout="true">${foo-parser-v_${version}}</stream-parser>
> >>>>> </command>
> >>>>>
> >>>>> assuming that the configuration file has furnished a definition of that parser.
> >>>>>
> >>>>> Al
> >>>>>
> >>>>>
> >>>>> ----- Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
> >>>>>> Al,
> >>>>>>
> >>>>>> I assume the "on-start-up" command is there (for example) to enable obtaining the version of the installed system. While this seems good, there also needs to be some way to select the parser based on this version. In other words, there needs to be a regex for each parser that is matched against the output of the "on-start-up" command that selects which parser is used for output from subsequent commands.
> >>>>>>
> >>>>>> Also, for commands that have minOcurrs="0", this implies that there can be multiple commands of this type, right? If so, I think there needs to be some ordering of the command execution (or do you assume it's the order the commands appear in the configuration file?)
> >>>>>>
> >>>>>> Greg
> >>>>>>
> >>>>>> On Jan 16, 2011, at 6:09 PM, Albert L. Rossi wrote:
> >>>>>>
> >>>>>>> Greg, Randy, Dave,
> >>>>>>>
> >>>>>>> I have posted a draft of the (control part) of the ResourceManager.xsd (http://wiki.eclipse.org/PTP/designs/resource_manager_xsd); please take a look when you get a chance.
> >>>>>>>
> >>>>>>> This is a valid XSD which will generate the necessary Java Classes using the JAXB compiler. I have not yet decided whether it will be simpler to use JAXB runtime to build the actual instance objects from valid instances of the XML, or whether we just might want to parse it in using a DOM parser and then pull from it as necessary.
> >>>>>>>
> >>>>>>> Let me know about the holes here, or what you don't think is going to work. Undoubtedly we will need to iterate a few times.
> >>>>>>>
> >>>>>>> Thanks, Al
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>>>
> >>>> _______________________________________________
> >>>> 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
>
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev
>
