2. Create Cluster

We will need to add support for create-cluster and delete-cluster commands. Create cluster will create the necessary configuration elements in domain.xml for a cluster. If --config option is not mentioned during create-cluster, it creates a copy of the default-config.

deploy command needs to support --target option where it will add the necessary application-ref for a target (cluster or stand alone instance).

For example,

<cluster config-ref="cluster1-config" ...>
      <server-ref disable-timeout-in-minutes="30" enabled="true" 
       lb-enabled="false" ref="instance1"/>
      <server-ref disable-timeout-in-minutes="30" enabled="true" 
       lb-enabled="false" ref="instance2"/>
      <application-ref disable-timeout-in-minutes="30" enabled="true" 
       lb-enabled="false" ref="applicationFoo"/>
      ...
 </cluster>

2.1 Token Support
GlassFish cluster definition will require token support where user will be able to specify port numbers, etc. to avoid conflicts. A token is defined as ${token} in domain.xml. The value of the token is then defined at config/cluster/server element level as system properties.

create-cluster has --systemproperties option that allows user to define the necessary tokens.

For example,

<config name="cluster1-config" ...>
...
    <http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" 
     default-virtual-server="server" enabled="true" family="inet" id="http-listener-1" 
     port="${HTTP_LISTENER_PORT}" security-enabled="false" server-name="" 
     type="default" xpowered-by="true">

    <!-- defines http port value for everyone using the config -->
    <system-property name="HTTP_LISTENER_PORT" value="8080"/> 
...
</config>

 <cluster config-ref="cluster1-config" ...>
     <!-- overrides http port value at config level -->
     <system-property name="HTTP_LISTENER_PORT" value="38080"/> 
 </cluster>

 <server config-ref="cluster1-config" ....>
     <!-- overrides http port value at cluster level for this server-->
     <system-property name="HTTP_LISTENER_PORT" value="38181"/>  
 </server>

XXX Config - We will need a mechanism to get un-processed token value for administration at GUI and CLI
XXX Do we really need a system-property at JVM level for this? Just replacing at the config bean level seems good enough.

Current v3 implementation
v3 observations

2.2 Support for Port Conflicts
GlassFish v2.x scans domain.xml and sets the appropriate tokens during cluster/instance creation. create-domain command has --checkports option that checks for port conflicts. create-domain also has option such as --portbase that allows user to define a base port for a domain during domain creation. We should continue to support these features (can be considered in phase 2 of this project after basic stuff is working).

Refer to this write-up for more details on exiting GlassFish v2.x behavior.

2.3 Manual Synchronization
Add a command that will return the necessary application and configuration bits for a given cluster. The bundle will contain relative path with the following content under domain dir from DAS:

||---- config (config files common to all servers including the DAS)
            | ---- domain.xml, etc.
            ||---- <server/cluster-name>-config (cluster/server-specific data)
     ||---- applications
            ||---- <application-name>
     ||---- java-web-start
            ||---- <application-name>
     ||---- generated
            ||---- ejb
                   ||---- <application-name>
            ||---- jsp
                   ||---- <application-name>
            ||---- policy
                   ||---- <application-name>
            ||---- xml
                   ||---- <application-name>
     ||---- lib (libraries common to all servers including the DAS)
     ||---- docroot (the default web-container docroot, files are copied to instance's docroot)

XXX We may include only deployed applications for a target as an optimization
XXX We may handle soft links

For example, on DAS machine user will do the following...

% asadmin generate-sync-bundle --target <cluster1>  </tmp/cluster1.zip>

User will FTP the newly created bundle zip from DAS server to remote instance machine(s) and apply the content using a local command.

For example,

% asadmin apply-sync-bundle --target <instance1> <cluster1.zip>
% asadmin apply-sync-bundle --target <instance2> <cluster1.zip>

Use Case Scenarios

1. Convenience Case: No direct communication between DAS and remote instances initially, until remote instances are created locally
2. Never Communication Case: Never any direct communication between DAS and remote instances - Out of scope, not supported

Use Case #1 - Convenience Case

1. Install GF3.1 on DAS
2. asadmin create-cluster c1
3. asadmin create-instance --cluster c1 --node remote i2 (Registers i2 with DAS but i2 filesystem is not created on remote instance since it is not available)
4. asadmin deploy --target c1 hello.war
5. Modify c1-config, like create a property
6. asadmin generate-sync-bundle --target c1 tmp/c1.zip (remote admin command)

--> Bundle contains subset of directories under domains/domain1

-  config (all files)
                   - domain.xml, etc
                   - c1-config  (c1 specific)
          - applications (c1 specific)
                   - hello
          - generated (c1 specific)
                   - jsp
                        - hello
           -lib (all files)
           -docroot (all files)

1. Install GF3.1 on remote Instance machine which can now communicate with DAS
2. asadmin --host DAS create-local-instance --cluster c1 --node remote i1 (rendezvous with DAS, creates local filesystem, das.properties)
3. asadmin --host DAS create-local-instance --cluster c1 --node remote i2
4. FTP c1.zip to Instance machine
5. asadmin apply-sync-bundle --target i1 --node remote c1.zip (local cli command)

--> Unzip c1.zip under nodeagents/remote/i1

Technical Requirements

1. generate-sync-bundle command should internally use synchronization code that will do a --fullsync to get everything. The output stream should go to the zip file located in DAS.
2. apply-sync-bundle should remove existing contents (applications/ generated/ config/ docroot/ lib/ java-web-start/) before unzipping the new content. If user defined a exclude (this will be a well known location; Bill to decide; refer to SYNC-007: Exclude user created files from cleanup), that should not be removed.

2.4 Ref Support
Section 2 talks about target support for deploy command. Similarly, we also need to add support for create-application-ref, delete-application-ref, create-resource-ref and delete-resource-ref commands that will allow user to associate an application or resource with a target.

Note: In this project, it is sufficient to create the application-ref or resource-ref in domain.xml and ensure that the associated applications/resources are loaded during server startup. Dynamic re-config or hot deployment project will deal with deploying the resource/application to the target server instance(s) dynamically.