"bstansberry(a)jboss.com" wrote : | anonymous wrote : So 'hotdeployment' is purely a profile implementation detail, how we reconcile local repositories across a cluster would be part of the org.jboss.profileservice.spi.DeploymentRepository.getModifiedDeployments() implementation. | | But that doesn't get to controlling how the profile changes get reflected in the runtime. That's a task of the MainDeployer and the deployers. | Ok, that is true. Additions/removals to the profile do need to be passed through the MainDeployer to bring a running system in sync with the profile. "bstansberry(a)jboss.com" wrote : | An ear is deployed on all 4 nodes of a cluster. New version of the ear is deployed. Goal is that the ear be brought to a certain deployment stage (DeploymentStages.REAL?) on all nodes in the cluster such that we know the deployment will work on all nodes. A 2PC "prepare". At that point a cluster-wide "commit" is executed, the deployments are brought to the final stage where they handle requests, and the old version is removed. If there is a failure during the "prepare", the new version is rolled back and the old version left in place. | Ok, DeploymentStages.REAL would be too far as real runtime components would start to be created. Maybe we would just need to run it through the DESCRIBE phase, maybe PRE_REAL. The main problem is a disconnect between a system that looks valid in terms of everything being there, vs actually having all of the runtime components in place. "bstansberry(a)jboss.com" wrote : | There can be other variations on the above, but the main point is there is a multistep deployment process that requires intra-cluster communication at various points. Who controls that process is my question -- doesn't seem like its a concern of the DeploymentRepository, also doesn't seem like a proper concern of a deployer. My last post mentioned "some variant of the HDScanner concept" but that's not it either; you're right, HDScanner is just a trivial link between the profile and the MainDeployer and shouldn't be made into something else. Seems like this is at least partly a concern of a cluster-aware MainDeployer. | There really is no one controlling entity other than the admin layer. The admin layer calling the profile service api to do the deployment is what triggers everything, dealing with failures and rolling back to the previous version, but all participants need to be properly written with dependencies in place to allow a failure to be unwound. "bstansberry(a)jboss.com" wrote : | This is the part I need to dig into more to get a better understanding of what you mean. Perhaps that will answer my question above. :) | It won't. The metadata repository is just a hiearchical source of metadata that has scopes that can be where server/cluster wide defaults are picked up. It has to fit into any cluster wide notions, but solves nothing in of itself. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152999#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...