3.1 Deployment Review

Document: 3.1DeploymentOnePager&version=11

Reviewer: VinceKraemer

Review date: May 24, 2010

Response date: May 24, 2010

Item Type Comment Response
Reference number Clarification/Enhancement/Correction/.... Detailed review comments Response from functional spec/one pager author
1 enhancement include references to all the projects that you are dependent upon... not just Dynamic reconfig. yes, updated the one pager to include references to all the sub projects which deployment are dependent on
2 enhancement can you make the dependencies clearer? If I was the owner of the 'admin project', I am not sure I could tell what you are waiting for. Or how to make sure that I meet your requirements yes, updated the one pager to list all sub projects in the dependencies section. It's harder to go down lower level than this for these particular sub projects, we are working closely with the owners of the sub-projects to make sure people are on the same page
3 clarification directory deployment to a cluster requires that the bits live on a shared file system or on a shared file system that is mounted in exactly the same place on all nodes that participate in the cluster the latter, have made the clarification in the one pager
4 enhancement the behavior of a deployment with multiple dd files seems hard to use... could we add an option to the deploy command that would let the user choose which dd file has the highest precedence? as this is glassfish server, the current precedence addresses the most common use cases. Not sure if there are use cases where user wants to have weblogic DD have the highest precedence. We could consider this option if there is any user request on this.
5 enhancement make the links to the bugs and rfes actual live links to the bugs and rfes... not just dead text... yes, updated the one pager to have live links
6 clarification Say I had a DAS, that manages two clusters and three stand-alone instances. User A deploys foo.war and activates it on one of the clusters and two of the sa instances. If user B wanted to find out where foo.war is deployed/activated, what command would I use... or would I need to issue multiple commands? To figure out where the application was deployed, you would need to use list-applications/components with a given target (when you specify the target as domain), it will show the deployed applications to all the targets. To figure out the activated/enabled state, you would need to use show-component-status command. We plan to enhance the list-applications/list-components command in v3.1 to show the enabled state with the --verbose option. So you would not need to use show-component-status command separately.