Update Apigee Edge 4.51.00 or 4.52.00 or 4.52.01 to 4.52.02

Apigee supports upgrading Edge for Private Cloud directly from version 4.51.00, 4.52.00, or 4.52.01 to version 4.52.02. This page describes how to perform such upgrades.

Who can perform the update

The person running the update should be the same as the person who originally installed Edge, or a person running as root.

After you install the Edge RPMs, anyone can configure them.

Which components must you update

You must update all Edge components. Edge does not support a setup that contains components from multiple versions.

Update prerequisites

Ensure the following prerequisites before upgrading Apigee Edge:

Backup all nodes
Before you update, we recommend that you perform a complete backup of all nodes for safety reasons. Use the procedure for your current version of Edge to perform the backup.
This allows you to have a backup plan in case the update to a new version doesn't function properly. For more information on backup, see Backup and Restore.
Ensure Edge is running
Ensure that Edge is up and running during the update process by using the command:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Ensure that the Cassandra Compaction Strategy is LeveledCompactionStrategy
Depending on your current version, perform the necessary changes to the Cassandra compaction strategy. Follow the steps below and then return to the main upgrade procedure:
- If you are upgrading from version 4.51.00, refer to the Cassandra Compaction Strategy document for v4.51.00.
- If you are upgrading from version 4.52.00, refer to the Cassandra Compaction Strategy document for v4.52.00.
- If you are upgrading from version 4.52.01, refer to the Cassandra Compaction Strategy document for v4.52.01.

What special steps to consider for upgrade

To upgrade to Edge for Private Cloud 4.52.02, consider running specific steps for upgrading certain software. Necessary steps depend on your current version. Refer to the table below for the various software requiring supplementary steps, and follow the detailed instructions for each. After completing the necessary tasks, return to the main upgrade procedure to continue the upgrade process.

Current version	Software that requires special steps for upgrade to 4.52.02
4.52.01	Cassandra
4.52.00	Zookeeper, Cassandra, Qpid
4.51.00	Zookeeper, Postgres, Cassandra, Qpid

After performing the necessary steps based on your version, return to the main upgrade procedure to continue.

Automatic propagation of property settings

If you have set any properties by editing .properties files in /opt/apigee/customer/application, those values will be retained after the update.

Upgrade to Zookeeper 3.8.3

Edge for Private Cloud 4.52.02 does not include a Zookeeper upgrade. However, if you are upgrading from a version older than 4.52.01, you are required to follow the Zookeeper upgrade steps outlined below.

If you are upgrading from Edge for Private Cloud versions 4.51.00 or 4.52.00, refer to the steps in Required upgrade to Zookeeper 3.8.3 to upgrade Zookeeper.
If you are upgrading from Edge for Private Cloud version 4.52.01, you should already be using Zookeeper version 3.8.3, and you don’t need to follow any special steps for upgrading Zookeeper.

Note:

Upgrading from Edge for Private Cloud 4.52.01 to 4.52.02 is simplified because Zookeeper and Cassandra are typically co-located on the same host or virtual machine, which removes the necessity for separate Zookeeper upgrade procedures alongside the significant Cassandra upgrade.

Should Zookeeper require updating with specific steps, upgrade Zookeeper across all data centers by updating one node at a time. Once all Zookeeper nodes globally are updated, then upgrade Cassandra one data center at a time, adhering to the procedure outlined later in this article.

The following command facilitates a separate Zookeeper upgrade:

/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile

For a Zookeeper rollback, use the standard zookeeper rollback procedure. If a rollback becomes necessary for Cassandra or other components, those components should be rolled back; a Zookeeper rollback is not required.

Upgrade to Postgres 14

If you are upgrading from Edge for Private Cloud 4.51.00 to 4.52.02, you must follow the steps to upgrade Postgres, even though Edge for Private Cloud 4.52.02 does not include a Postgres upgrade. Upgrading from Edge for Private Cloud 4.51.00 to 4.52.02 requires additional Postgres upgrade steps. Please refer to the Required upgrade to Postgres 14 section.
If you are upgrading from Edge for Private Cloud 4.52.00 or 4.52.01 to 4.52.02, no additional Postgres upgrade steps are required.

Upgrade to Cassandra 3.11.16

Apigee Edge for Private Cloud 4.52.02 includes an upgrade of Cassandra to version 3.11.16. Cassandra is a critical component of Apigee, and this upgrade also includes updates to the driver software in various runtime and management components used to query and write to Cassandra.

As this is a major upgrade, certain changes to Apigee’s data model in Cassandra were necessary to ensure optimal performance in newer versions. Although these changes are minimal, the upgrade process disrupts certain management APIs when the upgrade is kicked off. The exact management APIs that are generally disrupted are listed in relevant sections below.

Additionally, the upgrade process causes disruption to a larger set of runtime proxy flows and management APIs in the data center that is being upgraded. It is critical that you isolate your runtime and management traffic from the data center being upgraded so as to minimize such disruption. Read sections for single data center and multiple data centers below for more information.

Note: The cassandra-cli tool is no longer supported in Cassandra 3.X and is not available for your use.

Developer Portal - Documenting APIs

The Apigee Drupal developer portal offers various features for documenting your APIs. While it is recommended to transition away from using the Drupal 7-based developer portal, if you are still using it and utilizing its SmartDocs feature, Using SmartDocs APIs document applies to you. If you are using newer versions of the developer portal, there will be no impact on your API documentation during this upgrade.

When you upgrade Apigee to version 4.52.02, any API models created using the SmartDocs feature of the Drupal 7 developer portal will not be migrated to the newer version automatically. You are expected to manually export each model using the developer portal and import it again after completing the upgrade.

Terminology used below

Runtime: Runtime encompasses the handling of your runtime proxy traffic. It includes all operations performed by your Routers and Message Processors to effectively process a runtime API request for existing proxies. However, it does not include the deployment of new proxies or new revisions of proxies.

Management: Management includes the administration of your Apigee Edge system. This includes, but is not limited to, deployments, modifications of apps, products, target servers, keystores, etc. All management APIs (and their clients such as Apigee UI and developer portal) are included in this scope.

During this upgrade, Runtime and Management traffic is impacted in the region or data center (DC) where the update is being executed. Irrespective of the data center being updated, there is an impact to certain management APIs in all data centers. This impact is noted after each step.

In each step below, state of runtime and management is described as you progress through the various stages of the upgrade procedure.

Upgrade strategies

Multiple data centers

The upgrade must be performed one data center at a time to ensure traffic continuity and avoid downtime. Before upgrading a DC, traffic should be rerouted to other functional DCs.

Note:

To avoid traffic impact during the upgrade, follow a data center-by-data center (DC-by-DC) approach by temporarily redirecting traffic away from the data center being upgraded. This ensures a controlled upgrade process for Cassandra, Management Server, and Runtime nodes while maintaining service availability.

For a two data centers setup, follow these high-level steps:

Redirect traffic from DC-1 to DC-2 and block incoming traffic to DC-1.
Upgrade DC-1, including Cassandra, Management Server and Runtime components.
Redirect traffic back to DC-1 and block incoming traffic to DC-2.
Upgrade DC-2, including Cassandra, Management Server and Runtime components.

This process ensures seamless traffic management while performing the upgrade. A similar pattern should be followed for setups with more than two data centers, where traffic is temporarily redirected to data centers that are either fully upgraded or not yet upgraded.

Single data center

For a single data center setup, the upgrade procedure will encounter a significant impact on runtime traffic and certain management APIs. The following options are available for a single data center setup.

Expand your Edge for Private cloud cluster to a temporary data center by adding a data center alongside the existing one to handle traffic during the upgrade, then decommission one of the data centers upon completion of the upgrade process.
If you are unable to expand to an additional data center, prepare for downtime and schedule the upgrade during periods of low traffic to minimize the impact on management APIs and the runtime traffic.

It is advised to expand to an additional data center to avoid impact to runtime traffic and management APIs. During upgrade, impacts to the data center being upgraded include, but not limited to the following areas:

Runtime APIs refreshing OAuth tokens
Runtime APIs using Access Entity Policy
Management APIs listing developer apps
Management APIs listing products

The impact described above is in addition to the specific management APIs that will remain non-functional on all data centers until all data centers are upgraded. Such management APIs are listed in the steps in subsequent sections.

Rollback - high level

Impact During Rollback
Rolling back from Cassandra 3.11.x to 2.1.x affects both runtime and management traffic within the data center (DC) where the rollback is being performed. Additionally, certain management APIs may experience disruptions across all data centers, regardless of which DC is currently being rolled back.
Follow DC by DC Rollback Approach
Rollback must be executed one data center at a time to maintain service continuity and prevent downtime. Prior to initiating rollback in a specific DC, ensure that application traffic is rerouted to another fully operational data center.
Rolling Back Partially Upgraded Cluster
If at least one data center remains fully operational on the older version of Cassandra (2.1.22), other upgraded DCs can be rolled back by performing a rebuild from the fully functional Cassandra 2.1.X DC.
Cluster-Wide Rollback
If the entire Cassandra cluster has been upgraded and rollback is required, it must be performed using backups or VM snapshots. This approach is complex and will likely lead to temporary downtime or data loss.
Pre-Upgrade Considerations
It is important that you familiarize yourself with rollback procedures before attempting the upgrade. It is critical that nuances of rollback are being considered while upgrading to ensure appropriate rollback paths are available.

Rollback clusters with a single data center

Upgrading Cassandra from version 2.1.x to 3.11.x can significantly impact runtime traffic and certain management APIs. These impacts also apply during rollback and may result in downtime or data loss.

For production workloads, it is strongly recommended to provision a new data center prior to the upgrade. This allows for a safer rollback path without data loss or disruption to API traffic. The additional data center can be decommissioned after the upgrade is successfully completed.

If adding a new data center is not feasible but rollback capability is still required, ensure that reliable backups are taken prior to the upgrade. Restoring Cassandra 2.1.x from backups is possible, but this approach may involve service downtime and potential data loss.

Rollback clusters with multiple data centers

Rolling back multiple data centers follows a data center–by–data center (DC-by-DC) approach. In this approach, traffic from the data center being rolled back is redirected to other functional data centers, ensuring a controlled and isolated rollback process for Cassandra, Management Server, and Runtime nodes to avoid traffic disruption.

Refer to section Rollback the Cassandra 3.11.16 update for details.

Step 0: Start state

Zookeeper, Postgres and LDAP components are already upgraded to 4.52.02 versions. Your Edge for a private cloud cluster is stable and working. If rollback is required, the cluster will be rolled back to this state.
Cassandra in Apigee running with version 2.1.22.
Edge components:

Management-server communicating with Cassandra via older thrift protocol.
Runtime servers (Message Processors & Routers) communicating with Cassandra via older thrift protocol.

Runtime state at this stage	Management state at this stage
Runtime fully functional	Management fully functional

Step 1: Prepare for upgrade

The steps below are in addition to standard files that you typically create, such as Apigee’s standard configuration file for enabling component upgrades.

Change Cassandra to use LeveledCompactionStrategy.
Backup Cassandra using Apigee.
Take VM snapshots of Cassandra nodes (if feasible).
Create a Cassandra upgrade configuration file on each Cassandra node at /opt/apigee/apigee-cassandra/cass_upgrade.conf with the following contents:
```
# IP Address of node
HOSTIP=10.0.0.1

# Username for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_USERNAME=<cassuser>

# Password for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_PASSWORD=<casspass>

# Port for connecting to Cassandra via thrift. Optional. Defaults to 9160 if skipped.
CASS_PORT=9160

# Port for connecting to Cassandra via CQL. Optional. Defaults to 9042 if skipped.
CASS_CQL_PORT=9042

# Directory to be used by Cassandra upgrade scripts. Optional. Defaults to /tmp/cass_upgrade_scripts if skipped.
# Note that if upgrade is successful, this directory is deleted via root user - so provide a directory accordingly.
CASS_TMP_DIR=/tmp/cass_upgrade_scripts
    
```
If the file cannot be created at /opt/apigee/apigee-cassandra/cass_upgrade.conf, create the file /opt/silent.conf with the same contents on each Cassandra node.
Caution: Apigee’s upgrade installer will look for the file in the locations listed above. If the file is not present in either of the locations listed above, the upgrade will fail with a message like below:
```
could not read env location: '/opt/apigee/apigee-cassandra/cass_upgrade.conf'
file does not exist or cannot be sourced
could not read env location: '/opt/silent.conf'
file does not exist or cannot be sourced
```
If this happens, the upgrade will fail but Cassandra service on the node will likely be in a stopped state. You can start the Cassandra service as usual and reattempt the upgrade by placing the configuration file in any one of the expected locations. Additionally, if the file is found but the configurations provided are incorrect (for example, Cassandra credentials are incorrect), then the upgrade will fail with an error like below:
```
Error in PREIN scriptlet in rpm package apigee-cassandra-X.XX.XX-X.X.XXXX.noarch
```
In this case, similarly, start the Cassandra service if it is stopped when the upgrade fails and reattempt the upgrade after fixing configurations in the file.
If you use the SmartDocs feature of Apigee Drupal 7 developer portal, take an export of each of your models by downloading them in JSON format from the developer portal UI. These models will need to be imported back into Apigee after the management servers are updated.
Ensure that ports 9160 and 9042 are accessible from all Edge components to Cassandra nodes if not already present. Refer to Port requirements for more information.

Step 2: Redirect traffic away from the first data center

Block incoming runtime and management traffic from the first data center.
Redirect all runtime traffic and management APIs to the other functional data centers.
Validate that runtime and management traffic are successfully handled by the other DC(s).

Step 3: Upgrade all Cassandra nodes in the first data center

Upgrade all Cassandra nodes in the data center 1 by 1. Run the following commands on each node one by one:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```

Once a node is updated, run the following command on the node to run some validations before proceeding ahead:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile

The above will output something along the lines of:

Cassandra version is verified - [cqlsh 5.0.1 | Cassandra 3.11.16 | CQL spec 3.4.4 | Native protocol v3] Metadata is verified

Run the following post_upgrade command on each Cassandra node one by one after the upgrade is complete:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
```

Runtime state at this stage	Management state at this stage
Runtime traffic blocked on data centers being upgraded Runtime fully functional on other data centers	Management traffic blocked on data centers being upgraded. Following management function is degraded after Cassandra is upgraded in other data centers: Management API to create API product with environment Management API to update an API product with environment Management API to delete an organization

Step 4: Upgrade all management nodes in the first data center

Upgrade all management nodes in the data center:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Runtime state at this stage	Management state at this stage
Runtime traffic blocked on data centers being upgraded Runtime fully functional	Management traffic blocked on data centers being upgraded. Following management function is degraded after Cassandra is upgraded: Management API to create API product with environment Management API to update an API product with environment Management API to delete an organization

Step 5: Upgrade all runtime nodes in the first data center

Upgrade all Routers and Message Processor nodes in the data center one by one:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Runtime state at this stage	Management state at this stage
Runtime traffic blocked on data centers being upgraded Runtime fully functional on other data centers	Management traffic blocked on data centers being upgraded. Following management function is degraded after Cassandra is upgraded in other data centers: Management API to create API product with environment Management API to update an API product with environment Management API to delete an organization

Step 6: Redirect traffic back to the first data center

Once the First data center is upgraded with Cassandra, runtime components and management-server, re-enable runtime and management traffic to First data center.
Ensure the runtime and management traffic is successful across DCs.

Step 7: Upgrade other data centers

Repeat Step 1 to Step 6 on remaining data centers, one at a time by redirecting traffic away from such data centers, updating the Apigee software and re-enabling traffic on such data centers.

Step 8: Rerun upgrade step in all the Management nodes

Rerun the following upgrade command in all management nodes across data centers:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Step 9 - [Optional] Import smartdocs which were previously exported

Once all management servers are upgraded, you can import the smart docs models you had exported in Step 1. You can decide to do this later.

You only need to do this if you use Drupal 7 based developer portal and are using the smartdocs feature.

Runtime state at this stage	Management state at this stage
Runtime fully functional	Management fully functional

Step 10 - Drop Unused tables

Run the following command to drop old unused tables from the Cassandra cluster. Until this is run, you cannot use certain features of Cassandra (like setting up new authentication - old authentication mechanisms will continue to work). This command can only be executed on only one node in the cluster

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile

Step 11 - Upgrade all remaining Edge and other components for Private Cloud 4.52.02

Upgrade all remaining edge-qpid-server and edge-postgres-server nodes in all regions one by one.

At this stage, if you are upgrading from versions earlier than Edge for Private Cloud 4.52.01 as below to do additional steps for upgrading Qpid, Postgres respectively and upgrade remaining components as per these steps.

Upgrade to Qpid J-Broker

Even though Edge for Private Cloud 4.52.02 does not include an upgrade to Qpid, if you are upgrading from versions older than 4.52.01, you need to follow the steps to upgrade QPID.

If you are upgrading from Edge for Private Cloud 4.51.00 or 4.52.00 to 4.52.02, it is necessary to follow additional Qpid upgrade steps. Please refer to the Upgrade Qpid section if you are upgrading from version 4.51.00 or 4.52.00 to 4.52.02.
If you are upgrading from Edge for Private Cloud 4.52.01 to 4.52.02, you should already be using the latest version of the Qpid Broker, and no additional Qpidupgrade steps are necessary.

New Edge UI

This section lists considerations regarding the Edge UI. For more information, see The new Edge UI for Private Cloud.

Install the Edge UI

After you complete the initial installation, Apigee recommends that you install the Edge UI, which is an enhanced user interface for developers and administrators of Apigee Edge for Private Cloud.

Note that the Edge UI requires that you disable Basic authentication and use an IDP such as SAML or LDAP.

For more information, see Install the new Edge UI.

Update the Edge UI

To update the Edge UI component, consider the version of Edge for the Private Cloud that you are upgrading from:

From 4.51.00 to 4.52.00 (with the new Edge UI already installed): Use the upgrade instructions in this section for the edge-management-ui component.

Update with Apigee mTLS

To update Apigee mTLS , do the following steps:

Rolling back an update

In the case of an update failure, you can try to correct the issue, and then execute update.sh again. You can run the update multiple times and it continues the update from where it last left off.

If the failure requires that you roll back the update to your previous version, see Roll back 4.52.00 for detailed instructions.

Logging update information

By default, the update.sh utility writes log information to:

/opt/apigee/var/log/apigee-setup/update.log

If the person running the update.sh utility does not have access to that directory, it writes the log to the /tmp directory as a file named update_username.log.

If you do not have access to /tmp, the update.sh utility fails.

Zero-downtime update

A zero-downtime update, or rolling update, lets you update your Edge installation without bringing down Edge.

Zero-downtime update is only possible with a 5-node configuration and larger.

The key to zero-downtime upgrading is to remove each Router, one at a time, from the load balancer. Then, update the Router and any other components on the same machine as the Router, and add the Router back to the load balancer.

Update the machines in the correct order for your installation as described Order of machine update.
When it is time to update the Routers, select any one Router and make it unreachable, as described in Enabling/Disabling server (Message Processor/Router) reachability.
Update the selected Router and all other Edge components on the same machine as the Router. All Edge configurations show a Router and Message Processor on the same node.
Make the Router reachable again.
Repeat steps 2 through 4 for the remaining Routers.
Continue the update for any remaining machines in your installation.

Take care of the following before and after the update:

On combined Router and Message Processor node:
- Before update – perform the following:
  1. Make the Router unreachable.
  2. Make the Message Processor unreachable.
- After update – perform the following:
  1. Make the Message Processor reachable.
  2. Make the Router reachable.
On single Router nodes:
- Before update, make the Router unreachable.
- After update, make the Router reachable.
On single Message Processor nodes:
- Before update, make the Message Processor unreachable.
- After update, make the Message Processor reachable.

Use a silent configuration file

You must pass a silent configuration file to the update command. The silent configuration file should be the same one that you used to install Edge 4.50.00 or 4.51.00.

Update to 4.52.02 on a node with an external internet connection

Use the following procedure to update the Edge components on a node:

If present, disable any cron jobs configured to perform a repair operation on Cassandra until after the update completes.
Log in to your node as root to install the Edge RPMs.
NOTE: While RPM installation requires root access, you can perform Edge configuration without root access.
Install yum-utils and yum-plugin-priorities:
Note: If your operating system is RHEL 8.0 - 8.6, skip this step.
```
sudo yum install yum-utils
sudo yum install yum-plugin-priorities
```
Disable SELinux as described in Install the Edge apigee-setup utility.
If you are installing on Oracle 7.x, execute the following command:
```
sudo yum-config-manager --enable ol7_optional_latest
```

If you are installing on AWS, execute the following yum-configure-manager commands:

yum update rh-amazon-rhui-client.noarch
sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

If you are currently on Edge 4.51.00:
1. Download the Edge bootstrap_4.52.02.sh file to /tmp/bootstrap_4.52.02.sh:
```
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
```
2. Install the Edge 4.52.02 apigee-service utility and dependencies by executing the following command:
```
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
```
  Where uName:pWord are the username and password you received from Apigee. If you omit pWord, you will be prompted to enter it.
  
  By default, the installer checks that you have Java 1.8 installed. If you do not, the installer installs it for you.
  
  Use the JAVA_FIX option to specify how to handle Java installation. JAVA_FIX takes the following values:
  - I: Install OpenJDK 1.8 (default).
  - C: Continue without installing Java.
  - Q: Quit. For this option, you must install Java yourself.
3. Use apigee-service to update the apigee-setup utility, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
4. Update the apigee-validate utility on the Management Server, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
5. Update the apigee-provision utility on the Management Server, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
6. Run the update utility on your nodes by executing the following command:
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
  Do this in the order described in Order of machine update.
  
  Where:
  - component is the Edge component to update. Possible values include:
    - cs: Cassandra
    - edge: All Edge components except Edge UI: Management Server, Message Processor, Router, Qpid Server, Postgres Server
    - ldap: OpenLDAP
    - ps: postgresql
    - qpid: qpidd
    - sso: Apigee SSO (if you installed SSO)
    - ue: New Edge UI
    - ui: Classic Edge UI
    - zk: Zookeeper
  - configFile is the same configuration file that you used to define your Edge components during the 4.50.00 or 4.51.00 installation.
  You can run update.sh against all components by setting component to "all", but only if you have an Edge all-in-one (AIO) installation profile. For example:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
```
7. Restart the Edge UI components on all nodes running them, if you haven't done so already:
```
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
```
8. Test the update by running the apigee-validate utility on the Management Server, as described in Test the install.

If you later decide to roll back the update, use the procedure described in Roll back 4.52.02.

Update to 4.52.02 from a local repo

If your Edge nodes are behind a firewall, or are otherwise prohibited from accessing the Apigee repository over the Internet, then you can perform the update from a local repository, or mirror of the Apigee repository.#heading

After you create a local Edge repository, you have two options for updating Edge from the local repo:

Create a .tar file of the repo, copy the .tar file to a node, and then update Edge from the .tar file.
Install a webserver on the node with the local repo so that other nodes can access it. Apigee provides the Nginx webserver for you to use, or you can use your own webserver.

To update from a local 4.52.02 repo:

Create a local 4.52.02 repo as described in "Create a local Apigee repository" at Install the Edge apigee-setup utility.
NOTE: If you already have an existing repo, you can add the 4.52.02 repo to it as described in "Update a local Apigee repository" at Install the Edge apigee-setup utility.
To install apigee-service from a .tar file:
1. On the node with the local repo, use the following command to package the local repo into a single .tar file named /opt/apigee/data/apigee-mirror/apigee-4.52.02.tar.gz:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
```
2. Copy the .tar file to the node where you want to update Edge. For example, copy it to the /tmp directory on the new node.
3. On the new node, untar the file to the /tmp directory:
```
tar -xzf apigee-4.52.02.tar.gz
```
  This command creates a new directory, named repos, in the directory containing the .tar file. For example /tmp/repos.
4. Install the Edge apigee-service utility and dependencies from /tmp/repos:
```
sudo bash /tmp/repos/bootstrap_4.52.02.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
  Notice that you include the path to the repos directory in this command.
To install apigee-service using the Nginx webserver:
1. Configure the Nginx web server as described in "Install from the repo using the Nginx webserver" at Install the Edge apigee-setup utility.
2. On the remote node, download the Edge bootstrap_4.52.02.sh file to /tmp/bootstrap_4.52.02.sh:
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
```
  Where uName:pWord are the username and password you set previously for the repo, and remoteRepo is the IP address or DNS name of the repo node.
3. On the remote node, install the Edge apigee-setup utility and dependencies:
```
sudo bash /tmp/bootstrap_4.52.02.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
  Where uName:pWord are the repo username and password.
Use apigee-service to update the apigee-setup utility, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update 
```
Update the apigee-validate utility on the Management Server, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
Update the apigee-provision utility on the Management Server, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
Run the update utility on your nodes in the order described in Order of machine update:
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
Where:
- component is the Edge component to update. You typically update the following components:
  - cs: Cassandra
  - edge: All Edge components except Edge UI: Management Server, Message Processor, Router, Qpid Server, Postgres Server
  - ldap: OpenLDAP
  - ps: postgresql
  - qpid: qpidd
  - sso: Apigee SSO (if you installed SSO)
  - ue New Edge UI
  - ui: Classic Edge UI
  - zk: Zookeeper
- configFile is the same configuration file that you used to define your Edge components during the 4.50.00 or 4.51.00 installation.
  NOTE: The configuration file must be readable by the "apigee" user. To change the owner, use the following command:
```
chown apigee:apigee configFile
```
You can run update.sh against all components by setting component to "all", but only if you have an Edge all-in-one (AIO) installation profile. For example:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
```

Restart the UI components on all nodes running it, if you haven't done so already:

/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart

Test the update by running the apigee-validate utility on the Management Server, as described in Test the install.

If you later decide to roll back the update, use the procedure described in Roll back 4.52.02.

Order of machine update - upgrade from 4.51.00 (or) 4.52.00 (or) 4.52.01

The order that you update the machines in an Edge installation is important:

You must update all ZooKeeper nodes across data centers before upgrading all other components. If you are upgrading from Edge Private Cloud 4.51.00 (or) 4.52.00, you will also need to follow additional steps to upgrade zookeeper.
You must update Postgresql across all the data centers. If you are upgrading from Edge Private Cloud 4.51.00, you will also need to follow additional steps to upgrade postgres.
You must update LDAP nodes across all the data centers.
You must update all Cassandra, Management Server, Message Processor and Router nodes, one data center at a time, until all data centers are upgraded.
You must update edge-qpid-server & edge-postgres-server components across all data centers.
You must upgrade Qpid nodes across all data centers. If you are upgrading from Edge Private Cloud 4.51.00 (or) 4.52.00, you will also need to follow additional steps to upgrade Qpid.
Update Edge UI and New Edge UI, SSO nodes across all data centers.
There is no separate step to update Monetization. It is updated when you specify the -c edge option.
Note: After you update the Edge UI component, you must restart the Edge UI service, as described in the update installation instructions.

1-node standalone upgrade

To upgrade a 1-node standalone configuration to 4.52.02:

Update all components:

/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile

(If you installed apigee-adminapi) Updated the apigee-adminapi utility:

/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

2-node standalone upgrade

Update the following components for a 2-node standalone installation:

See Installation topologies for the list of Edge topologies and node numbers.

Update Zookeeper on machine 1:

/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile

Update Postgres on machine 2:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Update LDAP on machine 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Update Cassandra on machine 1:

/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile

Update Edge components on machine 1 and 2:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Update Qpid on Machine 2:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Update the UI on machine 1:

/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile

(If you installed apigee-adminapi) Updated the apigee-adminapi utility on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(If you installed Apigee SSO) Update Apigee SSO on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
Where sso_config_file is the configuration file you created when you installed SSO.

Restart the Edge UI component on machine 1:

/opt/apigee/apigee-service/bin/apigee-service edge-ui restart

5-node upgrade

Update the following components for a 5-node installation:

See Installation topologies for the list of Edge topologies and node numbers.

Update ZooKeeper on machines 1, 2, and 3:

/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile

Update Postgres on machine 4:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Update Postgres on machine 5:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Update LDAP on machine 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Update Cassandra on machines 1, 2, and 3:

/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile

Update Edge components on machines 1, 2, 3, 4, 5:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Update Qpid on machine 4:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Update Qpid on machine 5:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Update the Edge UI:
- Classic UI: If you are using the classic UI, then update the ui component on machine 1, as the following example shows:
```
/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
```
- New Edge UI: If you installed the new Edge UI, then update the ue component on the appropriate machine (may not be machine 1):
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
```
(If you installed apigee-adminapi) Updated the apigee-adminapi utility on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(If you installed Apigee SSO) Update Apigee SSO on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
Where sso_config_file is the configuration file you created when you installed SSO.
Restart the UI component:
- Classic UI: If you are using the classic UI, then restart the edge-ui component on machine 1, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- New Edge UI: If you installed the new Edge UI, then restart the edge-management-ui component on the appropriate machine (may not be machine 1):
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

9-node cluster upgrade

Update the following components for a 9-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

Update ZooKeeper on machine 1, 2, and 3:

/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile

Update Postgres on machine 8:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Update Postgres on machine 9:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Update LDAP on machine 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Update Cassandra on machine 1, 2, and 3:

/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile

Update Edge components on machines 1, 4, 5, 6, 7, 8, and 9 in that order:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Update Qpid on machines 6 and 7:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Update either the new UI (ue) or classic UI (ui) on machine 1:

/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

(If you installed apigee-adminapi) Update the apigee-adminapi utility on machine 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(If you installed Apigee SSO) Update Apigee SSO on machine 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
Where sso_config_file is the configuration file you created when you installed SSO.
Restart the UI component:
- Classic UI: If you are using the classic UI, then restart the edge-ui component on machine 1, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- New Edge UI: If you installed the new Edge UI, then restart the edge-management-ui component on the appropriate machine (may not be machine 1):
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

13-node cluster upgrade

Update the following components for a 13-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

Update ZooKeeper on machines 1, 2, and 3:

/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile

Update Postgres on machine 8:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Update Postgres on machine 9:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Update LDAP on machines 4 and 5:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Update Cassandra on machines 1, 2, and 3:

/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile

Update Edge components on machines 6, 7, 10, 11, 12, 13, 8, and 9 in that order:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Update Qpid on machines 12 and 13:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Update either the new UI (ue) or classic UI (ui) on machines 6 and 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
(If you installed apigee-adminapi) Updated the apigee-adminapi utility on machines 6 and 7:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(If you installed Apigee SSO) Update Apigee SSO on machines 6 and 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
Where sso_config_file is the configuration file you created when you installed SSO.
Restart the UI component:
- Classic UI: If you are using the classic UI, then restart the edge-ui component on machines 6 and 7, as the following example shows:
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- New Edge UI: If you installed the new Edge UI, then restart the edge-management-ui component on machines 6 and 7:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

12-node cluster upgrade

Update the following components for a 12-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

Update ZooKeeper on machines 1,2,3,7,8,9 in both DCs:

/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile

Update Postgres on machines 6,12 in both DCs:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Update LDAP on machines 1,7 in both DCs:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Block the traffic in DC-1 and make sure all the traffic rerouted to other DC-2

Update Update Cassandra on machine 1,2,3 in DC-1:

/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile

Update Management Server on machine 1 in DC-1:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Update Router, Message Processor on machine 2,3 in DC-1:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Unblock the traffic in DC-1 and validate the DC-1 and proceed with the DC-2 by blocking traffic in DC-2 and reroute the traffic to DC-1

Update Cassandra on machine 7,8,9 in DC-2:

/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile

Update Management Server on machine 7 in DC-2:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Update Router, Message Processor on machine 8,9 in DC-2:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Unblock the traffic in DC-2 and now, both DCs will handle traffic
Re-run the update command in all the management-server across DCs on machine 1 & 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Update edge-qpid-server & edge-postgres-server on machine 4,5,6,10,11,12 in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Update Qpid on machine 4,5,10,11 in both DCs:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Update either the new UI (ue) or classic UI (ui) in both DCs:

/opt/apigee/apigee-setup/bin/update.sh -c  [ui|ue] -f configFile

(If you installed apigee-adminapi) Update the apigee-adminapi in both DCs:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(If you installed Apigee SSO) Update Apigee SSO nodes in both DCs:
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
```
Restart the new Edge UI (edge-management-ui) or classic Edge UI (edge-ui) component in both DCs:
```
/opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart
```