Page Comparison

...

• Docker or proxy use — Gateway can now be configured for use either within a Docker environment or behind a proxy. The Gateway configuration has two new settings available (externalHTTPPort, externalHTTPSPort) per protocol: [scsp] and [cluster_admin], the Service Proxy. They only take effect when X-Forwarded-Proto is found on the request; Gateway uses X-Forwarded-Proto to determine which port to use. (CLOUD-3055)

• Metadata Translation — Gateway seamlessly moves custom metadata between SCSP and S3. It translates the metadata formatting between the protocols. It provides S3 and SCSP applications the ability to access each other's metadata. See Metadata Translation between SCSP and S3. (CLOUD-2919)

• Quota stability — Quota implementation has been significantly hardened, resolving general problems with frozen usage status/data and excessive emails from state changes. (CLOUD-3045)

• Fixed issues:

  • There were issues when enabling versioning or quotas through the Content UI. The fix prevents creation of duplicate (conflicting) domains in the storage cluster. (CLOUD-3019)

  • Updating certain Swarm configuration settings through the Gateway services proxy (port 91) sometimes required the sptid query argument value. (CLOUD-2999)

  • Gateway validates on startup that [storage_cluster] managementPassword is set whenever the ServiceProxy ([cluster_admin]) is enabled. (CLOUD-2617)

• New in 5.4.1:

  • Content Gateway has added support so that it can be used with Swarm UI 2.3. Note that 2.3 includes a new feed type, S3 Backup feed, which requires Swarm 11.

  • Several fixes were made related to S3 multipart uploads. (CLOUD-2994, CLOUD-3074)

Upgrade Impacts

• Swarm Storage Requirements — Gateway 5.4 requires a minimum back-end storage cluster version of 9.6. The storage cluster must be upgraded prior to installing this version of Gateway.

  • Releases of Gateway 5.1.3 and earlier are not compatible with Storage versions 9.2 or higher. For historic compatibility details, refer to the releases included with those distributions.

• RHEL/CentOS 6 Deprecation — Support for RHEL/CentOS 6 will be removed in the near future. Completing the transition to RHEL/CentOS 7 now assures a smooth upgrade path to future Gateway versions.

• Automatic service start must be re-enabled — After the upgrade, the service may not automatically start after a system reboot. To re-enable the service, run:
  "chkconfig --add cloudgateway" for RHEL/CentOS 6, or
  "systemctl enable cloudgateway" for RHEL/CentOS 7. (CLOUD-2819)

• ExpanDrive — ExpanDrive users must upgrade to ExpanDrive 6.1.0 with this version of Gateway; earlier versions report 403 Signature errors when creating a folder or uploading a large object. (CLOUD-2746)

...

1. Ensure Swarm storage cluster is upgraded to version 9 or later. This includes completing the migration to Elasticsearch 2.3 metadata search servers in conjunction with the Swarm 9 upgrade.

2. In your load balancer, disable traffic for one Gateway at a time and perform the following upgrade steps for that Gateway. Allow traffic to continue flowing to the other Gateways.

3. Upgrade the traffic-disabled Gateway.

   1. Stop the Gateway service.

      RHEL/CentOS 6

      Code Block
      language bash
      service cloudgateway stop

      RHEL/CentOS 7

      Code Block
      language bash
      systemctl stop cloudgateway

   2. Upgrade the Gateway service:

      Code Block
      language bash
      yum -y install caringo-gateway-{version}.rpm

   3. If using RHEL/CentOS 7, reload the systemd control scripts:

      Code Block
      language bash
      systemctl daemon-reload

   4. Review and merge any configuration changes to the gateway.cfg and logging.cfg files in the /etc/caringo/cloudgateway directory.  The new distribution versions are the *.rpmnew files.

   5. Start the Gateway service:

      RHEL/CentOS 6

      Code Block
      language bash
      service cloudgateway start

      RHEL/CentOS 7

      Code Block
      language bash
      systemctl start cloudgateway

   6. Confirm Verify the Gateway service is running. See the log and curl examples in "Verifying the upgrade," below.

   7. Upgrade the Content Portal:

      Code Block
      language bash
      yum -y install caringo-gateway-webui-{version}.rpm

4. In your load balancer, re-enable client traffic to the newly upgraded Gateway and repeat the process for your remaining Gateways.

...

1. Ensure Swarm storage cluster is upgraded to version 9 or later. This includes completing the migration to Elasticsearch 2.3 metadata search servers in conjunction with the Swarm 9 upgrade.

2. In your load balancer, disable traffic for one Gateway at a time and perform the following upgrade steps for that Gateway. Allow traffic to continue flowing to the other Gateways.

3. Upgrade the traffic-disabled Gateway. 

   1. Stop the Gateway service:

      Code Block
      language bash
      service cloudgateway stop

   2. Upgrade the Gateway service:

      Code Block
      language bash
      yum -y install caringo-gateway-{version}.rpm

   3. Review and merge any configuration changes to the gateway.cfg and logging.cfg files in the /etc/caringo/cloudgateway directory.  The new distribution versions are the *.rpmnew files.

   4. Start the Gateway service:

      Code Block
      language bash
      service cloudgateway start

   5. Confirm Verify the Gateway service is running. See the log and curl examples in "Verifying the upgrade," below.

   6. Upgrade the Content Portal:

      Code Block
      language bash
      yum -y install caringo-gateway-webui-{version}.rpm

4. In your load balancer, re-enable client traffic to the newly upgraded Gateway and repeat the process for your remaining Gateways.

...

After upgrading, you can check the Gateway's server log (default: /var/log/caringo/cloudgateway_server.log)  to confirm verify there are no startup errors. You are looking to confirm that verify the SCSP and/or S3 protocol services are running. This is an example from a server with both protocols enabled:

2015-09-30 11:01:10,382 INFO [main|0000000000000000] S3GatewayServlet: S3 API enabled
2015-09-30 11:01:10,382 INFO [main|0000000000000000] ScspGatewayServlet: SCSP API enabled

You can also confirm that verify the Gateway is responding to Management API requests by requesting the API version. This command is run from the Gateway and assumes the SCSP protocol is running on port 8080. Adjust the port and/or interface IP address if your configuration is different.

...