[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] Updated diagram and CRCs for resourcemanager package
|
Greg,
On Thu, 2006-04-20 at 12:00 -0600, Greg Watson wrote:
I have some quick answers to your questions, though they are premised
on the idea that much of what are currently in the IRM... interfaces
are strict subsets of their corresponding IP... interfaces. I stress
currently, since this design is, at this time, geared toward the view
only part of the resource management system. In the future iterations
of the resource management system there will be added functionality
to manage jobs within queues that may require the IRM and IP interfaces
to diverge. Again, I say "may" because this iteration has not been
specked out yet.
> 1. What is the relationship between IRMMachine, IRMNode, etc. and
> IPMachine, IPNode, etc?
There is one area where the respective interfaces are not currently
strict subsets, and that is the addition of the new attribute system.
There is additional functionality within the IP interfaces that I do
not think are required by the IRM system. That is the main reason
for factoring out the IRM interfaces separate from the IP interfaces.
Nathan and I briefly discussed the new attribute system. It may be
desired to backfit the current system with the new attribute design.
> 2. The IRMResourceManager interface retrieves a '...list of machines,
> nodes, jobs, process,...' Currently this is performed by the
> IMonitoringSystem/IControlSystem interfaces. Does IRMResourceManager
> supersede the other interfaces?
No. The existing concrete classes, e.g. OMPIMonitoringSystem, will
either implement the IRMResourceManager interface along with the
IMonitoringSystem/IControlSystem interfaces, or we will build a wrapper
around the existing concrete classes. Nathan and I decided that the
next step is that I should code up the proposed IRM interfaces and we
can hash out any differences between the IRM interfaces and the design
of the current system. These will probably include decisions as to
whether the IRM interfaces should just be added to the implementation
interfaces of the current concrete classes. If the IRM interfaces are
strict subsets of any modified designs then this will be a trivial
change (see discussion above about deviations from strict subsets).
> 3. Please provide details on how the Resource Manager interacts with
> the current model/interfaces, etc?
I think I may have touched on that in the above answer, if not, perhaps
we should discuss this in person, and then post the results of our
discussion to this mail-list.
> 4. Please provide a brief overview of the components (for example,
> what is the purpose of the attribute interfaces).
If you are asking a high level question about the need for the
IAttribute and IAttrDesc being interfaces instead of classes, then
I would say that this was to support varying the ways of imposing
a strict-weak ordering on the attribute values. Dates would have
a different ordering than you would infer from their string
representations. Float's and int's would have yet different comparison
operators defining their ordering. I envision this to be useful when
the user wants to sort her display on some attribute column in a view's
table.
I left out a detailed discussion of the CRCs for the attribute system,
since I felt the IAttribute and IAttrDesc interfaces were the only
public level interfaces that the rest of the resource management system
would interact with. The more detailed design entailing the
AbstractAttrDesc and AttibuteEnvelope were implementation details.
The AttributeEnvelope class and the interfaces below it were created
to allow one "Attribute" to be composed of one description and multiple
values.
The idea seemed necessary from looking at the output of lshosts on an
LSF system
lambda2:~ [3] > lshosts | head
HOST_NAME type model cpuf ncpus server RESOURCES
lambdaserve LINUX86 x86 1.0 2 Yes (linux)
lambdaserve LINUX86 x86 1.0 2 Yes (linux)
lambda LINUX86 x86 1.0 2 Yes (linux)
lambda2 LINUX86 x86 1.0 2 Yes (linux)
l1 LINUX86 x86 1.0 2 Yes (linux mem2 cpu1000)
l2 LINUX86 x86 1.0 2 Yes (linux mem2 cpu1000)
l3 LINUX86 x86 1.0 2 Yes (linux mem2 cpu1000)
l4 LINUX86 x86 1.0 2 Yes (linux mem2 cpu1000)
l5 LINUX86 x86 1.0 2 Yes (linux mem2 cpu1000)
lambda2:~ [4] >
If you notice the response in the RESOURCES column you notice a list of
attibute values corresponding to the one "RESOURCES" attribute
description. I wanted to be able to design for the ability to filter
on the individual attribute values. For example, if the user wanted to
filter the node list for those that include the "mem2" resource, then
we would only display l1, l2, l3, l4, and l5 in the node view.
Greg, does this help answer your questions?
Regards,
Randy
