Versions Compared

Old Version 2

changes.mady.by.user Glen Darling

Saved on

compared with

New Version Current

changes.mady.by.user Joseph Pearson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Status: In Progress

Sponsor User: IBM

Date of Submission:  

Submitted by: Glen Darling

Affiliation(s): IBM

<Please fill out the above fields, and the Overview, Design and User Experience sections below for an initial review of the proposed feature.>

Scope and Signoff: (to be filled out by Chair)

Open Horizon should enable "run-to-completion" services

Overview

It is useful to be able to deploy containers that just run until they complete, not daemon-like containers that are expected to continue running forever. Open Horizon currently only supports the latter run-forever model so when you have a run-once application you need to wrap it with a process that goes idle after completion (i.e., something like: "while true: sleep"). Also you have to ensure that upon restart (e.g., due to reboot, or power cycle) that the container does not cause damage by trying to run again.

This issue is described in more detail in https://github.com/open-horizon/anax/issues/2458

Design

Bruce has suggested this would best be implemented as a service attribute of, "doNotRestart".

User Experience

This issue has come up in many contexts. A couple of examples are deploying the NVIDIA GPU Operator, and installing the EdgeX Foundry suite. Others include Intel’s ORRA, and IBM's MVI.

When integrating with applications, they sometimes use a run-once container instead of a setup script.  It's just really convenient to put setup code into a container just like the application code, rather than putting it into a script on the host. Other similar container management tools support this mode of operation and Open Horizon should too.

Command Line Interface

(none)

External Components

(none)

Affected Components

<List all of the internal components (agent, MMS, Exchange, etc) which need to be updated to support the proposed feature. Include a link to the github epic for this feature (and the epic should contain the github issues for each component).>

Security

<Describe any related security aspects of the solution. Think about security of components interacting with each other, users interacting with the system, components interacting with external systems, permissions of users or components>

APIs

<Describe and new/changed/deprecated APIs, including before and after snippets for clarity. Include which components or users will use the APIs.>anax

Security

(none)

APIs

Likely there would be corresponding API changes.

Build, Install, Packaging

<Describe any changes to the way any component of the system is built (e.g. agent packages, containers, etc), installed (operators, manual install, batch install, SDO), configured, and deployed (consider the hub and edge nodes).>(none)

Documentation Notes

<Describe the aspects of documentation that will be new/changed/updated. Be sure to indicate if this is new or changed doc, the impacted artifacts (e.g. technical doc, website, etc) and links to the related doc issue(s) in github.>

Test

<Summarize new automated tests that need to be added in support of this feature, and describe any special test requirements that you can foresee.>This new feature would have to be documented, of course.

Test

This new feature would have to be tested, of course.