Enabling Developer Portal feature flags on OpenShift and Cloud Pak for Integration

Use a template override to update the installation CR with settings that control the default behavior of the Developer Portal subsystem.

About this task

You can add a template override to the Developer Portal subsystem CR to change the default behavior of the Portal subsystem, or to turn specific features on and off. Table 1 describes the available feature flags.

Table 1. List of available feature flags for the Developer Portal
Feature flag name Default value Pod Container Description
DISABLE_MEMCACHE false www admin

Controls whether the distributed in-memory cache is disabled.

From IBM® API Connect 10.0.5.6 Portal web sites use a distributed in-memory cache by default, instead of using cache tables in the main site database. This update provides better performance for web site operations, but does mean that the cache needs to be repopulated when any of the Portal pods or virtual machines are restarted, for example, during an upgrade. While the cache is being repopulated, there is a reduction in performance. You can set the DISABLE_MEMCACHE flag to true to disable the distributed in-memory cache for all Portal sites, both existing and new.

ENABLE_TRUSTED_REVERSE_PROXY false www admin

Controls whether the Drupal trusted_reverse_proxy module can manage the reverse proxies list.

If you have multiple load balancers and reverse proxies in your upstream network, and the perimeter module is triggered, the incorrect IP address might be banned rather than the intended client IP address. However, you can manage which IP addresses are banned by using the Drupal trusted_reverse_proxy module, and setting this feature flag to true.

The Drupal module inspects the x-forwarded-for headers to identify the reverse proxies, and trusts that the first IP address found in the list is the client IP. For example, in X-Forwarded-For: <client>, <proxy1>, <proxy2>, the client IP <client> will be banned. For more information about this module, see https://www.drupal.org/project/trusted_reverse_proxy.

To use this module, you must ensure that all of the proxies in your upstream network, including the ingress controller, are configured correctly so that the x-forwarded-for header is passed through to the portal-www pod. For example, the default behavior of the nginx-ingress-controller is to ignore the inbound x-forwarded-for header, and create a new one. To change this behavior, update the nginx-ingress-controller configmap with the following information:
data:
  compute-full-forwarded-for: "true"
  use-forwarded-headers: "true"
Warning: Enable this feature flag only if you trust your upstream reverse proxies, as it is possible to trick the x-forwarded-for header.
MEMCACHE_MEMORY_LIMIT "128" or "256" www admin

Controls the amount of memory that the distributed in-memory cache can use, before space is freed up by removing the least used entries.

The default memory limit value depends on your deployment profile, for example:
  • 8 GB profiles have 128 MB per portal-www pod.
  • 16 GB profiles have 256 MB per portal-www pod.
If you think that performance is consistently worse when using the in-memory cache, you can either disable it by using the DISABLE_MEMCACHE setting, or change the memory limit by setting a specific MEMCACHE_MEMORY_LIMIT value. Note that the value is always in MB, and is always set as a number enclosed in quotes, for example "512".
Note:
  • The cache is distributed across the pods, so an n1 8 GB profile has only 128 MB of in-memory cache storage, but an n3 8 GB profile has 3 x 128 MB of in-memory cache storage.
  • An empty site consumes about 3 MB of the memory cache.
  • A site with around 6000 objects (spread across APIs, Products, Apps, Consumer Organizations, and so on) can consume about 87 MB of in-memory cache when every object is cached. However, this consumption is not usually the case unless every single page in your site is accessed. You don’t need to be able to fit the entire cache of every single site into memory, as the less often used cache entries will be evicted, and their space reused for new cache entries.
PORTAL_SKIP_WEB_ENDPOINT_VALIDATION false www admin

Controls whether the Portal subsystem checks whether the Portal web endpoint is accessible.

Sometimes, the endpoint cannot be reached, for example due to the complexity of the networks. In which case the following type of error can be seen in the portal-www pod, and admin container logs:
An error occurred contacting the provided portal web endpoint: example.com
The provided Portal web endpoint example.com returned HTTP status code 504
You can disable the check by setting this flag to true.

Procedure

  1. If API Connect is already deployed, retrieve the name of the deployed CR by running the following command:
    oc get apiconnectcluster -n <APIC_namespace>

    If API Connect yet is not yet deployed, skip this step.

  2. Edit the apiconnectcluster CR by running the following command:
    oc edit apiconnectcluster <APIC_instance_name> -n <APIC_namespace>
  3. In the CR, append the feature flag definition to the end of the spec.portal section, making sure to adhere to the spacing used in the file.

    You can add multiple feature flags as follows:

    spec:
      template
      - containers:
          - env:
              - name: DISABLE_MEMCACHE
                value: 'true'
            name: admin
        name: ptl-www
    spec:
      template
      - containers:
          - env:
              - name: ENABLE_TRUSTED_REVERSE_PROXY
                value: 'true'
            name: admin
        name: ptl-www
    spec:
      template
      - containers:
          - env:
              - name: MEMCACHE_MEMORY_LIMIT
                value: '512'
            name: admin
        name: ptl-www
    spec:
      template
      - containers:
          - env:
              - name: PORTAL_SKIP_WEB_ENDPOINT_VALIDATION
                value: 'true'
            name: admin
        name: ptl-www
  4. Close and save the file with the following command:
    :wq

    The Developer Portal subsystem is updated to enable or disable features as specified.