What's new in Version 10.0.5.1

Version 10.0.5.1 product release

What's new for Developers

The API policy version must match the gateway policy version

The way that API Connect validates the API policy version has changed. In earlier releases, API Connect published the API if its policy version was considered to be compatible with the gateway's version. If no version was specified, the policy version defaulted to 1.0.0. However, the published API might then fail at the gateway if the API policy version didn't match the gateway policy version.

Now, API Connect mitigates the problem by validating the API policy version prior to publishing the API. This new behavior means that API Connect only publishes an API to the gateway if the API policy version exactly matches the version that is present on the gateway. In addition, if a policy version isn't specified, it no longer defaults to 1.0.0. If the version is incompatible with the gateway, a validation error is thrown that specifies the available versions.

Note that this change in behavior does not affect APIs that are already published.

For more information about adding policies to your assembly, see Adding OpenAPI 2.0 elements to your assembly or Adding OpenAPI 3.0 elements to your assembly.

More flexibility when customizing the preflow policies

You can now use the mode property to control how the preflow policies are applied. For more information, see Customizing the preflow policies.

What's new for API product managers

Analytics latency charts now show percentile levels

To assist in the investigation of latency anomalies, the latency charts now include percentile lines.

Advanced options now available on analytics REST API and toolkit CLI

Advanced query filters are now available when querying analytics data. See Example toollkit CLI operations and Analytics REST API.

Configure the visibility of Products at a Catalog or Space level

You can now modify your Catalog settings to define a visibility property at a Catalog or Space level. This setting then becomes the maximum level of visibility that is allowed for any Product that is published to that Catalog or Space. It can also be used as the default visibility setting for that Catalog or Space. For more information, see Configuring Product visibility in a Catalog.

Note that this is an additional feature that is disabled by default, so current Product visibility behavior is not affected. The new feature also doesn't affect any Products that are already published.

What's new for Developer Portal administrators

New commands are available in the Developer Portal command-line tool

The following commands for managing forums are now available in the Developer Portal command-line tool:

• forums:disable - Deletes any existing forums taxonomy terms, and then disables the Forum module for a given site.
• forums:enable - Enables the Forum module for a given site.

For more information, see Using the forums commands.

What's new for DevOps

Upgrade now available for API Connect version 2018.4.1.20 to version 10.0.5.1

You can upgrade directly to 10.0.5.1 from 2018 FP20 by following the appropriate instructions for your platform:

• Upgrading from v2018 on Kubernetes
• Upgrading from v2018 on OpenShift
• Upgrading from v2018 on VMware

API Connect version 2018.4.1.20 to version 10.0.5.1 form factor migration

You can now migrate from version 2018.4.1.20 or later to a different form factor on version 10.0.5.1 or later. For more information, see: Migrating from v2018 to v10 on a different form factor.

API Connect 10.0.5.1 uses a new version of cert-manager

• Kubernetes, VMware: cert-manager 1.7.1

  There is an additional step to upgrade cert-manager Upgrading subsystems on native Kubernetes. When you refer to cert-manager in your CRs or commands, the following values must be updated to reflect the newer version of cert-manager: In VMware, references to cert-manager in CRs are updated during the upgrade.

  • cert-manager-0.10.1.yaml becomes: cert-manager-1.7.1.yaml
  • ingress-issuer-v1-alpha1.yaml becomes: ingress-issuer-v1.yaml
  • certmanager.k8s.io becomes: cert-manager.io
• OpenShift, Cloud Pak for Integration: cert-manager 3.21 (provided by Foundational Services)
  Upgrade of cert-manager is done automatically during the API Connect upgrade. However, when you refer to cert-manager in your CRs or commands, the following values must be updated to reflect the newer version of cert-manager:

  • cert-manager-0.10.1.yaml becomes: cert-manager-3.21.yaml
  • ingress-issuer-v1-alpha1.yaml becomes: ingress-issuer-v1.yaml
  • certmanager.k8s.io becomes: cert-manager.io

New apicup commands for the rotation of secrets on the Developer Portal subsystem

The following commands are now available for the rotation of secrets on the Developer Portal subsystem on VMware:

• list-rotate-secrets - to obtain a list of any Developer Portal secret rotations that were created by using the rotate-secrets command.
• delete-rotate-secret - to delete any Developer Portal secret rotations that were created by using the rotate-secrets command.

For more information, see Tips and tricks for using APICUP.

Two site High Availability (HA) feature renamed to two site DR (2DCDR)

This feature has been renamed to avoid confusion with production HA deployment profiles, and to recognize the manual intervention required to failover to the passive data center. The passive data center in a 2DCDR configuration has also been renamed to the warm-standby datacenter. See Two data center deployment strategy.

Note: The terms passive and multiSiteHA are still used in the CR YAML files. This is a documentation change only, and there is no change in the behavior of 2DCDR.

New installation instructions for 2DCDR on Cloud Pak for Integration

The steps for installing API Connect on Cloud Pak for Integration in a 2DCDR configuration are now documented. See Installing a two data center deployment on Cloud Pak for Integration.

New installation instructions for 2DCDR on OpenShift

2DCDR installation on OpenShift is now documented in a dedicated topic, instead of sharing the topic with Kubernetes 2DCDR install. See Installing a two data center deployment on OpenShift.

Reorganization of Kubernetes, OpenShift, and Cloud Pak for Integration installation documentation

The installation documents for these platforms have been reorganized to provide a more sequential flow for the reader, and reduce the amount of non-applicable information presented to them; see Deploying on Kubernetes and Deploying on OpenShift and Cloud Pak for Integration.

Mutual TLS support for Management to Gateway communication

For individual subsystem installations on OpenShift and Kuberenetes, mutual TLS can be enabled with a new validateApimClient setting. See Installing Gateway on Kubernetes, Installing Gateway on OpenShift in a dedicated namespace, or Installing Gateway on OpenShift in a shared namespace depending on your deployment platform and topology.