DEPL4 — Target Manager Resource Commitment Granularity

At the moment, resources are committed and later released according to
a Deployment Plan – the Execution Manager just sends over the full
plan, and the Target Manager has to pick it apart. We considered this
a good idea – after all, the plan contains all information about
resources that will be used by an application. In retrospect, however,
it looks like a design break. The plan contains a lot of information
that the Target Manager is not interested in. So the Target Manager
has to dissect information that it should not need to see in the first
place.

Also, and maybe more importantly, the only way of releasing resources
is by sending the very same plan to the Target Manager all over again,
as the Target Manager does not keep track of allocations.

This does not allow for the early release of resources, in case the
application does not need all that were reserved, or in case part of
the application finishes early.

Therefore I propose to replace the current "commitResources" and
"releaseResources" operations with a per-application "resource
commitment" object that allows to commit and release resources in a
fine-grained manner, and that keeps track of the current commitment,
so that the remaining resources that are in use by an application
can be released by simply destroying the object.

By not sending the full Deployment Plan, that would also dramatically
cut communication between the Execution Manager and the Target Manager.

No Data Available