Overview

CCF4XAP 2.3.7.4 minor version is focused on the following features:

• The command line tool is available for download from http://gigaspacesversions.s3.amazonaws.com/gigaspaces-cloudtools-2.3.7.4.zip
• Cloud applications started with previous versions, should be shutdown before restarted with version 2.3.7.4.
• Added the ability to start machines without specifying the zone.
• Support attach of existing volumes formatted with any file system (xfs, ext3)
• Improve robustness of the deployment process.
• Database volumes are no longer automatically deleted at shutdown (so data is not lost)
• Discontinued support for deprecated xml nodes from version 2.3.6

Zones and Regions:

Added <region> node under <cloud-config> that specifies region for all machines.
The default configuration file defines:

<cloud-config>
   <region>us-east-1</region>
   ...
</cloud-config>

The <zone> node is optional. To specify a zone (which was the default in version 2.3.7.2) specify the following:
<zone>us-east-1a</zone>

To start all machines in the Europe region, specify:
<region>eu-west-1</region>

Note that all machines must run in the same region. Different machines may run in different zones inside the same region:

<cloud-config>
<region>eu-west-1</region>
<zone>eu-west-1a</zone>
...
   <gsm-machine>
      <zone>eu-west-1b</zone>
      ...
   </gsm-machine>
</cloud-config>

External EBS volumes

To attach an existing volume and mount as /vol use <ebs-volume-id> as follows:
<ebs-volume-id>vol-80fd05e9</ebs-volume-id>
The attached volume must be formated with a file system recognizable by linux (such as xfs or ext3).

To create and attach a new volume with specified size (GBs) and mount as /vol use <ebs-new-volume-size> as follows:
<ebs-new-volume-size>10</ebs-new-volume-size>
The new volume is formatted with the xfs file system.

Optionally you may specify the snapshot that used to create the new volume bu using <ebs-snapshot-id> together with <ebs-new-volume-size> as follows:
<ebs-new-volume-size>10</ebs-new-volume-size>
<ebs-snapshot-id>snap-6f970a06</ebs-snapshot-id>

Changes in deployment configuration xml file

Discontinued support for the following <cloud-config> nodes:

• <gsc-numof-machines>
• <gsc-per-machine>
• <gsm-numof-machines>
• <gsm-per-machine>
• <load-balancer>
• <load-balancer-filename>
• <use-cache>
• <mirror>
• <processing-units> ( deprecated only outside <gsm-machine> )
  Discontinued support for the following machine nodes:
• <script-target>
• <script-location-type>

Discontinued support for the following <database-machine> nodes:

• <database-url>
• <database-name>
• <database-user-name>
• <database-password>

Instead, specify database information explicitly in processing unit deployment info as follows:

<cloud-config>
...
   <database-machine>
      <name>Database</name>
      <gsc-per-machine>1</gsc-per-machine>
      ...
   </database-machine>

   <gsm-machine>
   ...
      <processing-units>
         <processing-unit>
            <name>$CPD/mirror.jar</name>
            <deploy-options>-zones Database -properties embed://data-source-url=jdbc:mysql://$DatabasePrivateIpAddress/petclinic;data-source-username=pc;data-source-password=pc
            </deploy-options>
         </processing-unit>
      </processing-units>
   </gsm-machine>

Gsm machine is always started after the database machine has been started. Use $DatabasePrivateIpAddress to pass the mirror database machine ip address to the relevant processing units. (Currently only one mirror database is supported per deployment).

All of the attached volumes described above are not deleted once cloud shuts-down. This is to preserve the information contained in the database.

Deprecated (but still supported) the following <database-machine> nodes:

• <snapshot-id> (replaced by <ebs-snapshot-id>)
• <size> (replaced by <ebs-new-volume-size>)
• <volume-id> (replaced by <ebs-volume-id>)

Deprecated mirror-override.xml file (but still supported) used in <database-machine>

Instead specify a gsc inside the database machine with <gsc-per-machine>1</gsc-per-machine> as described in the example above.

Improved Robustness

• All files transferred to S3 are uploaded only once.Subsequent machines added dynamically no longer transfer (the exact same files) to S3.
• Added retry mechanism for machines created but immediately terminated with an internal error.
• Handles case when terminated instance id is recycled by AWS (cannot query machine status after it has terminated).