/
Managing Dynamic Features

Managing Dynamic Features

Gateway has infrastructural support for optional features and extensions (such as https://perifery.atlassian.net/wiki/spaces/public/pages/2990833665) that can be drop into a Swarm implementation as desired. (v6.1)

Installing Dynamic Features

After obtaining the optional package for a feature, install it on the Gateways, along with any supporting frameworks needed, such as FFmpeg, which DataCore provides preconfigured within a Docker container.

Best Practice

Use Docker and install DataCore's provided container; this avoids dealing with third-party repository choices, dependencies, and resource reconfiguration required to protect Gateway's performance. Installing without the container requires assistance from DataCore Support. 

  1. Copy the package for the feature to a server running Content Gateway: 
    caringo-FEATURE-VERSION.noarch.rpm

  2. Upgrade to RHEL/CentOS 7 (required by Docker) if the server is running RHEL/CentOS 6.x.

  3. Upgrade Gateway (versions 6.1 and higher support drop-in features such as video clipping) if running Content Gateway 6.0 or earlier.
    See https://perifery.atlassian.net/wiki/spaces/public/pages/2443810147.

  4. Upgrade Content UI to support this feature if running version 6.1 or earlier. 
    See https://perifery.atlassian.net/wiki/spaces/public/pages/2443810310.

  5. Install the package.

    dnf install caringo-FEATURE-VERSION.noarch.rpm

    The installation creates a features.d directory under /etc/caringo/cloudgateway/, which is where Gateway detects optional, dynamic features.

  6. Install any additional frameworks, such as multimedia support via FFmpeg, which DataCore provides preconfigured in a Docker container. 
    From an Internet-connected machine: 

    1. Check whether Docker is installed: docker info
      Else, install the Docker package, start the daemon, check its status, and enable it system-wide. See https://docs.docker.com/install/linux/docker-ce/centos/.

    2. Verify Docker by running a container test:

      docker run hello-world

    3. Load the provided container: 

      docker load < caringo-gateway-VERSION.feature.FEATURE.via.docker.VERSION.x86_64

  7. Gateway creates the following directory for spooling content: /var/spool/caringo/cloudgateway/features
    Gateway refuses to start if it cannot create this directory.

  8. In setting  iptables rules, Docker closes external TCP access to port 80 (although ping and ssh work); explicitly open port 80 again so clients can access Gateway. 

    firewall-cmd --add-port=80/tcp --permanent firewall-cmd --reload systemctl restart docker

  9. Repeat the above process on any remaining Content Gateway servers.

  10. Restart the Gateway(s).
    On reboot, Content Gateway detects the feature; on a page refresh, Content UI displays the additional functionality, such as the clipping control for video content.

Metrics for Feature Usage

Dynamic features include a set of metrics providing visibility in to how each feature is being used. (v6.2)

These are the https://perifery.atlassian.net/wiki/spaces/public/pages/2443812753 metrics displaying dynamic features:

curl http://GATEWAY:9100/metrics -s | grep -i feature

caringo_gateway_feature_install_count

How many dynamic features are installed currently.

caringo_gateway_feature_invocation_count

How many times was the feature called, since the last Gateway restart.

caringo_gateway_feature_invocation_latency

How much time, on average, did successful calls for that feature take, since the last Gateway restart. For video clipping, this varies relative to the size of the clips being created.

caringo_gateway_feature_errors_count

How many times did the feature call fail, since the last Gateway restart.

See https://perifery.atlassian.net/wiki/spaces/public/pages/2443812753.

Audit Logging for Features

Each dynamic feature logs operations to provide auditing. When creating a video clip, for example, Gateway handles it asynchronously and acknowledges the request with an INVOKE message, which appears first in the audit log. That acknowledgement references the future JSON result object. When that JSON result later posts, it reports the outcome of the clipping request, such as the FFmpeg exit code and the duration, capturing the same information received on the response if it is synchronous.

2019-08-22 14:32:04,991 INFO [F38143E84D3EC62E] 2 192.168.1.154 192.168.1.154 Feature:videoclipping INVOKE user1 (none) 200 0 149 38.00 d1.example.com bucket1 inputMovie.mp4 2019-08-22 14:32:15,022 INFO [F38143E84D3EC62E] 2 192.168.1.154 192.168.1.154 Feature:videoclipping POST user1 (none) 201 641705 46 0.09 d1.example.com bucket1 outputClip.mp4 2019-08-22 14:32:15,061 INFO [F38143E84D3EC62E] 2 192.168.1.154 192.168.1.154 Feature:videoclipping POST user1 (none) 201 149 46 0.04 d1.example.com bucket1 inputMovie.mp4.F38143E84D3EC62E.json

All JSON result objects are temporary, by default: they are created with a lifepoint that triggers deletion after 5 days. Change the default in the https://perifery.atlassian.net/wiki/spaces/public/pages/2443810201, gateway.cfg ([dynamic_features] resultObjectLifetime=5).

See https://perifery.atlassian.net/wiki/spaces/public/pages/2443822661.

© DataCore Software Corporation. · https://www.datacore.com · All rights reserved.