D&C Spec Locality & DAnCE Support
OMG D&C 4.0 spec sections 7.3.9 and 7.3.10 cover locality constraints for deployments, defining a LocalityKind enumeration with 6 different settings. From the spec:
In the DAnCE implementation of the D&C execution model, per its supported .cdp descriptor file format for a deployment plan, the only enum value we have ever used to date to specify the <constraint> tag value for a <localityConstraint> entry is "SameProcess", which maps to the 2nd enum.
My basic question, which comes indirectly from ongoing deployment planning tooling work, is whether DAnCE will support the other 5 enumerations if they show up in a .cdp file - either syntactically from a schema standpoint (error?), or semantically in terms of actually doing something intelligent with them?
Given the standard DAnCE behaviors of 1) auto-creating a default locality manager component server process instance for any defined component instance which is not explicitly coupled with one via a SameProcess constraint, and 2) use of a (required?) explicit <node> tag/value for every <instance> in a .cdp file, it would seem like the only LocalityKind enum that even has value in practice would be SameProcess.
Moreover, use of this particular constraint is the only way that I'm aware of to either collocate two component or connector fragment instances in the same process, OR to associate at least one component instance with an explicit, non-default, process instance upon which <configProperty> values have been set. But again, given the # 1 and # 2 DAnCE behaviors described above, it would seem like even if these other enum options were settable syntactically, they could either be safely ignored or would otherwise be overridden through the per-instance <node> tag values.
Comments or thoughts?
LocalityConstraints
Hi Mark -
Good question :-)
OMG D&C 4.0 spec sections 7.3.9 and 7.3.10 cover locality constraints for deployments, defining a LocalityKind enumeration with 6 different settings. From the spec:
In the DAnCE implementation of the D&C execution model, per its supported .cdp descriptor file format for a deployment plan, the only enum value we have ever used to date to specify the <constraint> tag value for a <localityConstraint> entry is "SameProcess", which maps to the 2nd enum.
To be slightly pedantic, the LocalityKind enum that you've described above is actually not part of the deployment plan. The LocalityKind is used in the packaging descriptors and is intended to be used by a planning actor/agent/program to arrive at the final DeploymentPlan.
The locality constraints allowed in the CDP are actually of the type PlanLocalityKind, which has only SameProcess, DifferentProcess, and NoConstraint.
My basic question, which comes indirectly from ongoing deployment planning tooling work, is whether DAnCE will support the other 5 enumerations if they show up in a .cdp file - either syntactically from a schema standpoint (error?), or semantically in terms of actually doing something intelligent with them?
As a result of the above, there will be a schema error if you try to use a LocalityKind in a deployment plan. There will be no error if you limit yourself to the three allowed PlanLocalityKind elements.
Given the standard DAnCE behaviors of 1) auto-creating a default locality manager component server process instance for any defined component instance which is not explicitly coupled with one via a SameProcess constraint, and 2) use of a (required?) explicit <node> tag/value for every <instance> in a .cdp file, it would seem like the only LocalityKind enum that even has value in practice would be SameProcess.
Moreover, use of this particular constraint is the only way that I'm aware of to either collocate two component or connector fragment instances in the same process, OR to associate at least one component instance with an explicit, non-default, process instance upon which <configProperty> values have been set. But again, given the # 1 and # 2 DAnCE behaviors described above, it would seem like even if these other enum options were settable syntactically, they could either be safely ignored or would otherwise be overridden through the per-instance <node> tag values.
Comments or thoughts?
Your analysis, as usual, is spot on. Right now, we only really use PlanSameProcess when calculating locality constraints. This is an intentional decision to keep our algorithm simple and provide deterministic mappings of instances to processes. PlanDifferentProcess and PlanNoConstraint are ignored.
Now, let's say for a moment that the DeploymentPlan used the LocalityKind enum that you outlined above (i.e., 6 values). My feeling is that this is putting too much intelligence into the deployment tool. My thought would be that we'd not want the ExecutionManager/LocalityManager making these kinds of decisions (i.e., mapping components to nodes). Such a job would be better suited for a run-time planner that acts as an agent for the executor.
In this case, the executor would provide a plan/package descriptor to the run-time planner. This plan/package would not necessarily have any node assignments in it. The run-time planner would consult the TargetManager (were it implemented, at the moment it is not) to determine available resources. Armed with this knowledge, it could interpret those constraints in light of available resources and priorities/security constraints, and produce a CDP, which could then be passed to the plan_launcher.
As an aside, the CDP structure sometimes doesn't make a whole lot of sense and starts to seriously break down and become a significant bottleneck for larger deployments. I think we need to use the next specification process to seriously consider how we might adjust the structure to make it easier to parse and analyze.
Re: LocalityConstraints and dynamic deployments
Hi,
Sorry to butt in, but as one of the more recent authors of the Split_Plan functionality, which takes care of the processing of the Locality constraints, I have to correct something here.
The current algorithm does most definitely also take PlanDifferentProcess into account (it used to be only PlanSameProcess but that's quite a while back already ;-) ). So, two instances that are included in a Locality constraint for PlanDifferentProcess will be assigned different Locality managers (actually what the splitter does is create subplans at a locality level and assigns the instances to those subplans in the end making sure each subplan has a locality manager instance defined).
The splitter works from the assumption the planner (tool or person) has set up the Locality constraints in the deployment plan in a logically compatible way so it does not attempt to check whether f.i. two instances have been added to both PlanSameProcess and PlanDifferentProcess constraints.
The CDP structure is nothing more than an implementation specific 'physical' representation of the actual deployment model (just as the IDL derived datastructure is).
I don't think the specification process should be focussing on the representation forms of the model as much as on updating the specs to allow for more dynamic/flexible implementations. F.i. by formally adding progressive deployments and deployment reconfigurations to the spec the need for huge, static deployment plans would simply vanish.
D&C PlanLocalityKind
Hi Will,
Thanks for the response and explanation! Oops - yes you're right it's the PlanLocalityKind enum defined in the Execution Data Model section 7.7 (7.7.5.1 & 7.7.6.5), with only the 3 possible settings you mention. Much better since the tag values match exactly. I had seen 6 possible settings in a tool demo, did a search in the spec and stopped at the LocalityKind enum without realizing that was defined in the Component Data Model earlier in the spec.
So, good that the other 2 enums can be set, but as expected they don't do anything. That answers my question, and I'll pass it along.
Always interesting to read about alternative preparation or launch phase sequencing possibilities utilizing other management elements from the D&C spec. In this case a yet-to-be-implemented TargetManager that would actually utilize plan/package descriptors - which we don't currently even generate, much less use.
Our approach, per the current DAnCE implementation, is quite a bit more static. We do not take advantage of potential run-time load balancing or other dynamic adaptation approaches to modify the .cdp at run-time. In some scenarios I can see where this might be quite useful. But in some of our more common real-time and high performance computing (HPC) cases, I'd be concerned about the additional run-time latencies of adding to the launch phase sequence, and whether or not the constraints could be specified to a high enough level of fidelity to actually result in a deployment mapping that would satisfy the needs of some of our systems.
Even if higher fidelity constraints & deployment policies could be captured for HPC applications, they may end being so restrictive that there is only one possible deployment solution (or none), in which case it may as well have been specified directly in a .cdp during the deployment planning phase via a tool with a human in the loop. Plus, there's the trust issue, and whether many HPC & real-time architects would trust a dynamic deployment algorithm to lay down their components in the "right way," vs. do hand-tuning of their deployment. But again, it might be nice to have a more dynamic launch phase capability utilizing plan/package descriptors for systems that could take advantage of it.
Looking ahead to a possible v5.0 revision of the D&C spec, there is another area of the .cdp structure defining an <implementation> entry that is redundant (and therefore a common source of errors during generation) and appears to needlessly add to file size. Each <implementation> entry defines a nice compact xmi:idref reference to the <artifact> entries in the file that define it, e.g., an executor and a servant artifact. The referenced <artifact> entry itself defines each artifact's name, plus its important <location> tag value. However, each <implementation> entry also defines a much larger <execParameter> tag block for each of these artifacts, apparently simply for the purpose of duplicating the artifact name. At least in the current implementation, I don't see any value-added in the large ExecutorArtifact and ServantArtifact <execParameter> tags entries at all. The artifact name <string> information there, at least as produced by current tooling, is totally redundant & already captured by the referenced <artifact> entries themselves in much more compact form.
.02