Lifecycle Coordinator Upgrade Notes for 2018.0.0

This document provides information applicable to upgrading Lifecycle Coordinator to version 2018.0.0.

In addition to a number of new features such as promotion support for orchestrated APIs, there are a few significant changes to Lifecycle Coordinator (LC) to consider when upgrading from 8.4 to 2018.0.0.

Promotion User's Guide

API Platform Version: 2018.0.0 and later.

Table of Contents

  1. What is Lifecycle Coordinator?
  2. Deployment
  3. Authentication
  4. Configuration Designer authentication
  5. Synchronizing tenant data
  6. Runtime Configuration support
  7. Migration scenarios:
  8. Additional information

What is Lifecycle Coordinator?

Lifecycle Coordinator (LC) is a separate configurable feature that coordinates promotion across multiple instances of API Platform tenants. It can be deployed standalone or can be co-located with a tenant (or multiple tenants in the SaaS environment). Lifecycle Coordinator governs the promotion process and the transfer of data between environments.

Note: Extended Properties and Lifecycle Coordinator both leverage the underlying capabilities of Lifecycle Repository to extend Community Manager functionality. Extended Properties is an optional feature of the Akana API Platform, and Lifecycle Coordinator is a separate product.

They offer completely different feature sets:

  • The Extended Properties feature allows you to define custom properties and gather custom information from developer portal users.
  • Lifecycle Coordinator allows you to define a one-way topology that includes a chain of environments reflecting the development lifecycle. For example, the topology chain could be from Development to Testing to Staging to Production. Each environment is a separate installation of the developer portal.

    Lifecycle Coordinator is a standalone user interface that's installed separately. This feature also includes modifications to the developer portal user interface to allow the API Admin or app developer to promote the app or API to the next environment.

Back to top


With the 2018.0.0 release, the Lifecycle Coordinator feature is assumed to be co-deployed with Community Manager, with at least one local tenant to which authentication is delegated.

This is assumed to be the case even in a standalone Lifecycle Coordinator deployment where all tenants in the topology are remote from the LC instance. An existing topology set up to use LDAP, configured through Lifecycle Manager, will not be impacted. However, any new topology created will by default expect a local tenant to be specified in one of these ways:

  • By using the userAuthenticationSource property on a local tenant in the topology.
  • By designating a local tenant that is not in the topology by using the authentication-tenant-id topology property.

For more information on setting up these properties, with examples, see Delegated Authentication (Promotion Guide)

Back to top


As mentioned above, LC will now by default expect to delegate authentication to a local Community Manager tenant, regardless of whether the tenant is included in the topology.

However, it is still possible to use the Lifecycle Manager LDAP connection for authentication. This is accomplished by creating a topology with the topology property authentication-mode set to ldap (the default value is platform). For example:

	"name": "Topology1",
	"properties" : [
	"environments": [...],
	"tenants": [...]

Login to the LC UI is available to authorized users from the tenant designed in the userAuthenticationSource property.

Note: When a topology is configured to use the Lifecycle Manager LDAP domain, users from this domain will not be able to authenticate through the new DevOps standalone Lifecycle Coordinator feature introduced in the 2018.0.0 release. Users of standalone Lifecycle Coordinator UI must be Community Manager users.

Back to top

Configuration Designer authentication

With a topology library in the default authentication mode, connections from Lifecycle Manager's Configuration Designer must now specify the actual user ID of the connection user rather than the email address. You can get the user ID:

  • In Lifecycle Manager: In the account field of the user details page.
  • In Community Manager: In the URL of the user's profile page.

Back to top

Synchronizing tenant data

To allow validation of APIs and apps being promoted, LC must have an overview of the entities that exist in the target environment.

With the 2018.0.0 release, LC updates this information with a single periodic call for each environment.

The frequency of this polling is controlled by a configuration property in the Akana Administration Console:

Configuration > com.akana.lifecycle.coordinator > lifecycle.coordinator.config.tenantSyncInterval

The default is five minutes.

With this approach, it might take a period of time up to the length of the interval for LC to become aware of a newly created entity in a target environment (for example, a new policy).

Back to top

Runtime Configuration support

With the 2018.0.0 release, Lifecycle Coordinator now supports configuration of the Lifecycle Manager Runtime Configuration functionality within the topology definition itself, using the configuration property on environments in the topology. This avoids the need to explicitly create Runtime Configuration assets within the Lifecycle Manager user interface, and combines the two configuration concepts (promotion and Runtime Configuration) into a single document.

For information on environment configuration, see Environment Configuration (Promotion Guide).

Back to top

Migration scenarios

There are two possible migration scenarios:

Existing co-located Lifecycle Coordinator

If Lifecycle Coordinator was already co-located with a Community Manager tenant in the topology, there is no change necessary. Note that connections to the topology library from Configuration Designer must use Community Manager User IDs; see Configuration Designer authentication above.

Existing standalone Lifecycle Coordinator

No change is necessary for an existing topology. However, any newly-created topology must specify ldap as the authentication-mode (see Configuration Designer authentication above). Alternatively, a CM tenant can be deployed locally for the purpose of authentication and specified as the authentication tenant for the new topology.

Back to top

Additional information

For more information about using Lifecycle Coordinator, refer to the following:

Back to top