Steve, thanks for the comments.

I don't think it a good idea to assume any implicit dependencies/ordering among the deployments and I don't see the value of the assumption about idempotency.  Let me try explain them in my not so good English.

1. Idempotency

When we permit a deployment to be applied more than once even if we already see it failed or complete, we have to put a warning somewhere so users will know it and be very careful when writing their SoftwareConfig.peroperties.config scripts.  This means software packages may get downloaded again, a service may be restarted, a database table is recreated, a user account for the application is registered again ... or whatever.  For the user, he/she has to make a lot more efforts due to the 'idempotency' assumption we have on deployments.  Deployments are not just trivial meta-data, they are supposed to perform various actions by materializing the work demanded by a SoftwareConfig.

One possible solution is to make os-*-config much more sophisticated, so that it can figure out whether and when to apply a deployment. That means we need to change both the Heat side and the os-*-config logic.  Heat will specify whether a SoftwareDeployment is supposed to be applied once, or to be applied whenever any other SoftwareDeployment has been changed. I don't think we are going that far down this road.

I am aware of the idempotency design of some CM tools.  Even in those cases, the in-instance agent is smart enough to check whether a change should be applied.  But I am not convinced that we really want to impose that requirement to os-*-config components.

2. Dependency

Having all deployments automatically reapplied whenever any changes happen to one of them?  Personally, I think that is a side-effect (if you don't think it a bug) of always having all deployments listed in the metadata.  

My understanding is that we are introducing other triggers for SoftwareDeployment beyond the existing { CREATE, UPDATE, ... } collection.  We are in fact extending it to include { CREATE_OF_OTHER_SDS, UPDATE_TO_OTHER_SDS, ... }.

There are already many other ways to express dependencies among deployments, EXPLICITLY.  If a user has one deployment (A)  dependent on another (B), he/she is supposed to express this dependency in the template, rather than just having them appear in the same list in the metadata.

The user has the final decision what should be done when one of deployment is changed.  If only A need to be changed, that is all that will be included in the list.  If however, both A and B need to be changed, he will explicitly create two derived configs.

3. Ordering/Timing

As for ordering, I agree with you.  The only thing we need to do is to let the users know: deployments, when applied simultaneously, are executed in name order.  

Even after we have applied the first level of filter so that only IN_PROGRESS deployments to appear when metadata are built, there are still more work to do, as implied in your timestamp based proposal.  A deployment A may be still underway (IN_PROGRESS) when another deployment is changed (which is also IN_PROGRESS).  In that case, we may need one more status (inside the VM), say 'NEW'.  Then, os-*-config will know which deployment should be applied.  I don't think timestamp is a good idea, by the way.