Hi Karl, Karl Czajkowski wrote:
On Apr 27, Karl Czajkowski loaded a tape reading: ...
<jsdl:Resources> <jsdl:TotalCPUs>jsdl:rangeValue</jsdl:TotalCPUs> ? ... other totals for RAM, VM, etc. ... <jsdl:Resource> <jsdl:Count>jsdl:rangeValue</jsdl:Count> ? <jsdl:CPUs>jsdl:rangeValue</jsdl:CPUs> ? ... other per-resource constraints ... </jsdl:Resource> *
<jsdl:Resources /> *
</jsdl:Resources> *
I have changed the cardinality as I think it should be if we want the general case:
0-N Resources clauses since a job may have none? 0-N Resource clauses per Resources because it may have only "global" constraints 0-N nested Resources if you want the hierarchical model. in this case, we need to define whether "global" attributes summarize all Resource + Resources children or ONLY Resource children. I advocate the first total summation of all children.
I can appreciate the generality of this proposal but I'm wondering if we could get away with a smaller change to the spec at this stage? For example, keep the <jsdl:Resource> sections as in the current spec and introduce a separate <jsdl:AggregateResources> (or similarly named) section instead. I vaguely recall (but couldn't locate) an email where you proposed something like that. So, how about <jsdl:AggregateResources> <jsdl:TotalCPUs>jsdl:rangeValue</jsdl:TotalCPUs> ? ... other totals for RAM, VM, etc. ... <jsdl:AggregateResources> ? <jsdl:Resource> <jsdl:Count>jsdl:rangeValue</jsdl:Count> ? <jsdl:CPUs>jsdl:rangeValue</jsdl:CPUs> ? ... other per-resource constraints ... </jsdl:Resource> * I think doing it this way would also allow us, if we want, to structure the Aggregate Resources section as an extension to the base JSDL spec and include it in the specification in the same way as POSIXApplication.
to address Andreas's problem, I think we should add an attribute to the Resources element:
<jsdl:Resources resourceModel="spaceshare"> ...
And put this attribute on the <jsdl:Resource> element.
we need to define a few values and also assert a default model to assume if it is not present. I suggest spaceshare as the default because I am biased towards batch jobs. :-)
I like the values and their definitions. And I second the proposal that spaceshare should be the default. :-)
- spaceshare: the resources content describes the virtual "portion" of resource that the job gets to use, which MAY be a small part of a larger physical resource complex
- physical: the resources content describes a real physical resource complex (for Andreas's provisioning use case)
- virtual: should we presume a virtual machine version of the physical scenario? this seems to be a new popular datacenter trick to get "mainframe" like behavior from commodity hardware...
- other: some other extended content SHOULD identify the model interpretation to apply.
karl
Cheers, Andreas