Lifecycle Coordinator Installation

Provides information about how to install the Lifecycle Coordinator feature.

For information about using Lifecycle Coordinator, see Lifecycle Coordinator Promotion Guide.

Table of Contents

Overview

To install Lifecycle Coordinator, you'll essentially follow the same process as to install the Akana API Platform; see Installing the Akana API Platform. However, there are specific installation options you should choose, and there is some additional information you should be aware of. Before installing, review the information in the sections below.

Installing the Lifecycle Coordinator feature

For an on-premise installation of the Akana API Platform, the Lifecycle Coordinator feature must be separately installed from the Akana Administration Console:

Lifecycle Coordinator feature

Installing Lifecycle Coordinator implicitly installs the Lifecycle Repository feature as well. After selecting Lifecycle Coordinator for installation, the user is guided through a number of configuration tasks for the Lifecycle Repository feature.

Note: If the above option is not available, you will first need to install the Repository Manager ZIP file. For instructions, see Installing Repository Client (for the Lifecycle Coordinator or Extended Properties features)

Checking for database-specific requirements

Depending on the database version you're using, there might be additional steps you need to take. You should perform these steps after installation and before the additional configuration steps.

For details of the requirements for specific database types and versions, refer to the database notes section of the Akana API Platform installation documentation. Specifically, there are notes for Microsoft SQL Server and MySQL relating to installation of Lifecycle Repository.

Complete any applicable steps before continuing.

Securing the Topology REST API

There is also a task to secure the Topology REST API, as shown below.

Set Topology API Credentials task

This sets up the credentials for basic authentication on calls to the Topology REST API.

Remote container address (com.soa.promotion)

If the Lifecycle Coordinator is installed remotely, a URL to the remote container hosting the Lifecycle Coordinator instance must be configured for each container hosting tenants from which promotion can be requested.

To set this up:

  1. In the Akana Administration Console, open the Configuration tab.
  2. Select the com.soa.promotion category.
  3. Set the remote.promoter.address property to the host address of the container hosting the Lifecycle Coordinator instance. An example is shown below.

    Setting remote.provider.address

  4. Save the changes.

Properties to secure the Topology REST API (com.akana.lifecycle.coordinator)

You can set up the global configuration properties for Lifecycle Coordinator in the Akana Admin Console.

With the three properties listed below, you can configure the Topology REST API to require basic authentication for all requests.

  1. In the Akana Administration Console, open the Configuration tab.
  2. Select the com.akana.lifecycle.coordinator category.
  3. Set the properties. For details, see com.akana.lifecycle.coordinator properties below.
  4. Save the changes.

com.akana.lifecycle.coordinator properties

lifecycle.coordinator.config.apiUser
This field and the next are used to set the global basic authentication credentials for the Topology REST API. If this property is left empty, the Topology API will not require authentication of requests.
lifecycle.coordinator.config.apiPassword properties
If a value was set for lifecycle.coordinator.config.apiUser, specify the password.
lifecycle.coordinator.config.enableTenantScopedAuthentication
Boolean. Used to allow delegation of authentication to the primary tenant in the topology being acted on. The primary tenant is the tenant marked as the userAuthenticationSource in the topology. If no tenant is marked as the userAuthenticationSource, the initial tenant in the topology is used for authentication.
To be able to access the Lifecycle Coordinator user interface, a user must be registered in the tenant that's specified as the userAuthenticationSource and must also be assigned one or both of these roles, in Policy Manager: LC User or LC Administrator. See Who can use the Lifecycle Coordinator UI?

The following table summarizes the authentication behavior.

Global Credentials Set Tenant Scoped Authentication Enabled Behavior
No N/A Requests are not authenticated
Yes false Requests must specify global credentials
Yes true

Requests can specify either of these:

  • The email and password of a site admin user in the primary tenant of the topology being acted on.
  • The global credentials

Note: Requests for the getTopologies method (GET /lc/api/topologies) must specify the global credentials since there is no specific topology being acted on.

Unique ID Mapping behavior

When a source and target environment exist in the same API Platform instance, it is necessary to assign new unique IDs (keys) to the internal objects, such as services, that make up an API or app being promoted. This is because the keys must be unique across the API Platform instance, regardless of which tenant they exist in.

By default, Lifecyle Coordinator determines whether to preserve the keys of the promoted objects, or to assign new keys, based on whether the source and target environments exist in the same API Platform instance:

  • If the source and target environments coexist in the same API Platform instance, the platform assigns new keys.
  • If the source and target environments are in different API Platform instances, the platform preserves the original keys from the source environment.

In certain situations, it might be necessary to override the default key handling behavior. For example, assume that environment A is in one API Platform instance and environments B and C coexist in another API Platform instance. If a topology is configured to promote from environment A to environments B and C in parallel, the default key handling algorithm will attempt to assign the same keys to objects promoted to each environment, B and C. The result would be that one of the promotions would fail. In this case, you can override the default key handling behavior by setting the preserve-keys property on one of the Promotion Profiles involved. For example, the Promotion Profiles for environment A would be configured as shown below.

"promotionProfiles": [
{
    "name": "B Promotion",
    "targetEnvironment": "B"
  },
  {
    "name": "C Promotion",
    "targetEnvironment": "C",
    "properties" : [
      {"name":"preserve-keys","value":"false"}
    ]
  } 
]

With this approach, the promoted keys in environment B would match those of the source, while environment C would have new keys assigned, eliminating conflict between the two co-located target environments.

Note: Be cautious in using the preserve-keys property. If the source and target environments are on the same API Platform instance, and the property is set to true, promotions will fail.

Default "From Email" setting

You can set the default from email address used in emails sent from Lifecycle Coordinator, in the repository.config.defaultFromEmail property of the com.soa.repository configuration category.

You can also override the from email address for a specific topology. To do this, go into the topology library as an admin user or superuser, click Support Center, click Configure Library and set the Sender Email field, as shown below.

URL: {container-base-url}/lm/application/access/suLogin.do.

Setting From Email in LM

Configuration properties for the Promotion feature

There are specific configuration properties, configured in the Akana Administration Console for the container, that allow you to configure aspects of the Lifecycle Coordinator promotion feature.

These include:

Configuration category: com.soa.repository

Used to configure the tenant synchronization interval. Lifecycle Coordinator periodically updates cached policy and organization information for tenants referenced in a topology. The specific interval for this update is controlled by the property below.

repository.config.tenantSyncInterval
Sets the interval, in milliseconds, between updates to cached policy and organizational information.
Default: 300000 milliseconds (5 minutes)

Configuration category: com.soa.promotion

API Platform Version: 2019.1.0 and later

Used to control how often Lifecycle Coordinator updates cached policy and organization information for tenants referenced in a topology.

Note: These properties are available in the Akana Administration Console for the instance of the Community Manager developer portal that will be connecting with Lifecycle Coordinator.

remote.promoter.address
The address for the remote system that will be promoting Lifecycle Coordinator data to this instance of the Community Manager developer portal.
Address format: http(s)://{lc_host}:{lc_port}.
For more information about this setting, see Remote container address (com.soa.promotion).
tenant.api.maxAsyncExecutorThreads
Determines how many concurrent asynchronous promotion requests the Community Manager developer portal will allow. If requests are submitted that exceed this number, an HTTP error 503 (Unavailable) is returned.
Default: 8.
If you find you need to increase this setting, make sure enough CPU cores are available, and consider possible impact on system performance.
tenant.api.maxAsyncPromotionCacheMinutes
Determines the period of time, in minutes, for which an asynchronous promotion result will be available to be retrieved. After this time period, the result is dropped from the cache.
This should be set to the same value as the maxAsyncPromotionRequestMinutes setting below.
The apiplatform.remote.maxAsyncPromotionRequestMinutes setting determines the cache time period for Lifecycle Coordinator, the sender of the promotion-related messages; the tenant.api.maxAsyncPromotionCacheMinutes setting determines the corresponding period for the Community Manager developer portal, the receiver of the messages.
Default: 60 minutes.

Configuration category: com.akana.lifecyclemanager.apiplatform.remote

API Platform Version: 2019.1.0 and later

Used to control how often Lifecycle Coordinator updates cached policy and organization information for tenants referenced in a topology.

Note: These properties are available in the Akana Administration Console for the Lifecycle Coordinator container.

apiplatform.remote.maxAsyncPromotionRequestMinutes
Determines the period of time, in minutes, for which an asynchronous Lifecycle Coordinator promotion request to the Akana API Platform should be kept alive while waiting for a result.
This should be set to the same value as the maxAsyncPromotionCacheMinutes setting above.
The apiplatform.remote.maxAsyncPromotionRequestMinutes setting determines the cache time period for Lifecycle Coordinator, the sender of the promotion-related messages; the tenant.api.maxAsyncPromotionCacheMinutes setting determines the corresponding period for the Community Manager developer portal, the receiver of the messages.
Default: 60 minutes.