4.19.06 Edge for Private Cloud release notes

Mint not rating transactions initially

Edge for the Private Cloud does not rate transactions initially when you first enable monetization for an organization. This applies to new and existing organizations.

The monetization enablement API responds with the job ID and, upon completion, the status of the job will indicate success. However, any monetized API calls made initially will not be processed by monetization and will not be rated. These transactions will only show up in regular analytics.

Workaround:

apigee-service edge-message-processor restart

After monetization has been enabled, restarting the MPs causes Edge to load the configuration from ZooKeeper at startup. This happens on every restart, which means that the issue only applies initially.

Mint rating servers memory leak

When a new Qpid instance is registered in an mxgroup, the queues build without consumers, which results in the queue depth growing until it uses all available resources.

Workaround:

Metadata file format for apigee-sso install

When installing apigee-sso and using a metadata.xml file instead of a URL, if the metadata.xml file does not include a new line (CRLF) at the end of the file, the metadata.xml file is not read entirely.

Workaround:

To work around this issue, you can do one of the following:

• Add a CRLF to the end of the metadata.xml file

  OR

• Use a URL-based location for the metadata

apigee-monit not supported on Amazon Linux 1

Workaround:

Message Processor backup not backing up the correct set of files

Workaround:

Run the backup a second time and it should back up the correct set of files.

DataAccessException in multiple data center configurations

In multiple data center configurations, if one datastore becomes unavailable, then you might see the following error:

DataAccessException: Error while accessing datastore;
Please retry later

The result is that Management Server may not start because it is trying to connect to Cassandra nodes in both dc-1 and dc-2. The DataAccessExceptions occurs if a Cassandra node is down. This might also result in API traffic disruption, where Message Processors report DataAccessExceptions while trying to retrieve KVMs.

Note that the expected state is for the Management Server not to connect to datastore components across regions.

Workaround

The workaround is to deregister the following Cassandra node types in the unavailable data center and then re-register them after the Cassandra nodes are available again:

• kms-datastore
• dc-datastore
• keyvaluemap-datastore

To deregister and reregister these Cassandra node types:

1. Get the UUIDs of the Cassandra nodes by using the following curl command:

   curl -u ADMIN_EMAIL:ADMIN_PW \
     "http://MS_IP:MS_PORT/v1/servers?region=REGION&pod=GATEWAY_POD \
     &type=CASSANDRA_NODE_TYPE"

   Where:

   • ADMIN_EMAIL and ADMIN_PW are the credentials of your Apigee account.
   • MS_IP and MS_PORT are the Management Server's IP address and port number.
   • REGION is the name of the data center in which the Management Server is located.
   • GATEWAY_POD is the pod name, which is by default "gateway". You might have renamed it to something else, though, so check your implementation.
   • CASSANDRA_NODE_TYPE is one of kms-datastore, dc-datastore, and keyvaluemap-datastore.

   For example:

   curl -u nickdanger@google.com:myP@$$w0rD
     "http://192.168.0.1:8080/v1/servers?region=dc-1&pod=gateway&type=dc-datastore"

   The response uses the following format:

   {
     "internalIP" : "POD_IP_ADDRESS",
     "isUp" : [true|false],
     "pod" : "GATEWAY_POD",
     "reachable" : [true|false],
     "region" : "dc-1",
     "tags" : {
       "property" : [ ]
     },
     "type" : [ "kms-datastore", "dc-datastore", "keyvaluemap-datastore" ],
       "uUID" : "POD_UUID"
   }

   For example:

   {
     "internalIP" : "192.168.1.11",
     "isUp" : false,
     "pod" : "gateway",
     "reachable" : false,
     "region" : "dc-1",
     "tags" : {
       "property" : [ ]
     },
     "type" : "dc-datastore",
     "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
   }

   Note the values of the uUID field in the response. You will use these to deregister the nodes.

2. Repeat step one for each Cassandra node type: kms-datastore, dc-datastore, and keyvaluemap-datastore. Be sure to take note of the UUIDs that are returned.
3. Deregister the nodes using the following command:

   curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers/UUID" -X DELETE

   Where UUID is the UUID returned in the previous command's response.

4. Repeat step 3 for each UUID you collected in steps 1 and 2.
5. Re-register the nodes using the following command:

   curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers -d \
     "Type=kms-datastore&Type=dc-datastore&Type=keyvaluemap-datastore& \
     Type=counter-datastore&Type=cache-datastore&InternalIP=POD_IP_ADDRESS& \
     region=REGION&pod=GATEWAY_POD" -H \
     'content-type: application/x-www-form-urlencoded' -X POST

Note that these operations register and deregister nodes from Zookeeper and do not have any impact on the Cassandra cluster. For more information about these commands, see Update datastore registrations.

MessageLogging policy including extra information in the log message

The FormatMessage element of the MessageLogging policy controls the format of the logged message. When FormatMessage=false, the logged message is not supposed to include any Apigee-generated information. However, even if you set FormatMessage=false, the log message still includes the following information:

• The priority score
• The timestamp

Workaround: