Removing 'Docker' from 'Compose' (#80)

* removing 'Docker' from 'Compose'

Signed-off-by: Arne Broering <arne.broering@siemens.com>

* Removing 'Docker' from 'Compose' - fixes

Signed-off-by: Arne Broering <arne.broering@siemens.com>

---------

Signed-off-by: Arne Broering <arne.broering@siemens.com>

Author: arne-broering

src/margo-api-reference/workload-api/application-package-api/application-description.linkml.yaml

@@ -216,15 +216,15 @@ classes:
         range: HelmComponent
         rank: 20
 
-  DockerComposeDeploymentProfile:
+  ComposeDeploymentProfile:
     is_a: DeploymentProfile
     #rank: 66
     slot_usage:
       type:
-        equals_string: "docker-compose"
+        equals_string: "compose"
         rank: 10
       components:
-        range: DockerComposeComponent
+        range: ComposeComponent
         rank: 20
 
   Component:
@@ -251,7 +251,7 @@ classes:
     is_a: Component
     #rank: 73
 
-  DockerComposeComponent:
+  ComposeComponent:
     is_a: Component
     #rank: 76
 
@@ -276,7 +276,7 @@ classes:
         rank: 40
         range: string
       packageLocation:
-        description: URL indicating the Docker Compose package's location.
+        description: URL indicating the Compose package's location.
         rank: 50
         range: string
       keyLocation:
@@ -323,7 +323,7 @@ classes:
         description: >-
           The name of the parameter in the deployment configuration. 
           For Helm deployments, this is the dot notation for the matching element in the `values.yaml` file. This follows the same naming convention you would use with the `--set` command line argument with the `helm install` command. 
-          For docker-compose deployments, this is the name of the environment variable to set.
+          For compose deployments, this is the name of the environment variable to set.
         rank: 10
         range: string
         required: true
@@ -561,15 +561,15 @@ slots:
     description: >-
           Indicates the components's deployment configuration. 
           The values are `helm.v3` to indicate the component's package format is Helm version 3 
-          and `docker-compose` to indicate the component's package format is Docker Compose. 
+          and `compose` to indicate the component's package format is a Compose file. 
           When installing the application on a device supporting the Kubernetes platform all `helm.v3` components, 
           and only `helm.v3` components, will be provided to the device in same order they are listed in the application description file. 
-          When installing the application on a device supporting docker-compose all `docker-compose` components, 
-          and only `docker-compose` components, will be provided to the device in the same order they are listed in the application description file. 
+          When installing the application on a device supporting Compose all `compose` components, 
+          and only `compose` components, will be provided to the device in the same order they are listed in the application description file. 
           The device will install the components in the same order they are listed in the application description file.
     range: string
     required: true
-    pattern: ^(helm\.v3|docker-compose)$
+    pattern: ^(helm\.v3|compose)$
     rank: 10
 
   components:

src/margo-api-reference/workload-api/application-package-api/resources/examples/valid/ApplicationDescription-002.yaml

@@ -34,7 +34,7 @@ deploymentProfiles:
           repository: oci://northstarida.azurecr.io/charts/northstarida-digitron-orchestrator
           revision: 1.0.9
           wait: true
-  - type: docker-compose
+  - type: compose
     components:
       - name: digitron-orchestrator-docker
         properties:

src/margo-api-reference/workload-api/application-package-api/resources/index.md.jinja2

@@ -33,7 +33,7 @@ The application description has the purpose of presenting the application, e.g.,
 {% endfor -%}
 
 {% for c in gen.all_class_objects()|sort(attribute='rank') %}
-{%- if c.name != "ApplicationDescription" and not c.name.startswith("ComponentProperties") and not c.name.startswith("Helm") and not c.name.startswith("DockerCompose") %}
+{%- if c.name != "ApplicationDescription" and not c.name.startswith("ComponentProperties") and not c.name.startswith("Helm") and not c.name.startswith("Compose") %}
 
 {# if c is a subclass of any: #}
 
@@ -74,17 +74,15 @@ The expected properties for the suppported deployment types are indicated below.
 | wait | bool  | N  | If `True`, indicates the device MUST wait until the helm chart has finished installing before installing the next helm chart. The default is `True`. The Workload Orchestration Agent MUST support `True` and MAY support `False`. Only applies if multiple `helm.v3` components are provided.|
 | timeout | string      | N   | The time to wait for the component's installation to complete. If the installation does not completed before the timeout occurs the installation process fails. The format is "##m##s" indicating the total number of minutes and seconds to wait. |  
 
-- Properties for `docker-compose` components
+- Properties for `compose` components
 
-> **Investigation Needed**: We need to have more discussion about how docker-compose should be handled and what is required here.
-> We also need to determine if there is a version of docker-compose that needs to be specified. The docker compose schema [version has been
-> deprecated](https://github.com/compose-spec/compose-spec/blob/master/spec.md#version-and-name-top-level-elements) so it's not clear what we would even use for this if we wanted to.
+> **Investigation Needed**: We need to have more discussion about how Compose should be handled and what is required here.
 
 | Attribute      | Type  | Required?     | Description    |
 | --- | --- | --- | --- |
-| packageLocation  | string |  Y  | The URL indicating the Docker Compose package's location. |
+| packageLocation  | string |  Y  | The URL indicating the Compose package's location. |
 | keyLocation    | string | N  | The public key used to validated the digitally signed package. It is highly recommend to digitally sign the package. When signing the package PGP MUST be used.|
-| wait | bool  | N  | If `True`, indicates the device MUST wait until the Docker Compose file has finished starting up before starting the next Docker Compose file. The default is `True`. The Workload Orchestration Agent MUST support `True` and MAY support `False`. Only applies if multiple `docker-compose` components are provided.|
+| wait | bool  | N  | If `True`, indicates the device MUST wait until the Compose file has finished starting up before starting the next Compose file. The default is `True`. The Workload Orchestration Agent MUST support `True` and MAY support `False`. Only applies if multiple `compose` components are provided.|
 | timeout | string      | N   | The time to wait for the component's installation to complete. If the installation does not completed before the timeout occurs the installation process fails. The format is "##m##s" indicating the total number of minutes and seconds to wait.|
 
 ## Defining configurable application parameters

src/margo-api-reference/workload-api/desired-state-api/desired-state.linkml.yaml

@@ -128,15 +128,15 @@ classes:
         range: HelmComponent
         rank: 20
 
-  DockerComposeDeploymentProfile:
+  ComposeDeploymentProfile:
     is_a: DeploymentProfile
     rank: 40
     slot_usage:
       type:
-        equals_string: "docker-compose"
+        equals_string: "compose"
         rank: 10
       components:
-        range: DockerComposeComponent
+        range: ComposeComponent
         rank: 20
 
   Component:
@@ -162,7 +162,7 @@ classes:
     is_a: Component
     rank: 50
 
-  DockerComposeComponent:
+  ComposeComponent:
     is_a: Component
     rank: 50
 
@@ -213,7 +213,7 @@ classes:
 
 slots:
   type:
-    description: The type of deployment profile (e.g., helm.v3, docker-compose).
+    description: The type of deployment profile (e.g., helm.v3, compose).
     range: string
     required: true
     rank: 10

src/margo-api-reference/workload-api/desired-state-api/resources/examples/valid/DesiredState-002.yaml

@@ -8,7 +8,7 @@ metadata:
     namespace: margo-poc
 spec:
     deploymentProfile:
-        type: docker-compose
+        type: compose
         components:
             - name: digitron-orchestrator-docker
               properties:

system-design/app-interoperability/local-registries.md

@@ -1,18 +1,18 @@
 # Local Registries
 
-This section investigates options for configuring the usage of local Docker (or Helm Chart) registries. The goal of configuring such local registries is to avoid the reliance on public, Internet-accessible registries. The reasons for not using such public registries are mainly twofold: (1) publicly hosted Docker images or Helm charts could become unavailable at some point, as the owner decides to take the Docker images or Helm charts off the public registry, (2) Internet connectivity may not be available to the device and hence public registries are not reachable, or (3) end-users want to host their own registries so they can do security scans and validate the packages.
+This section investigates options for configuring the usage of local OCI-based container (or Helm Chart) registries. The goal of configuring such local registries is to avoid the reliance on public, Internet-accessible registries. The reasons for not using such public registries are mainly twofold: (1) publicly hosted container images or Helm charts could become unavailable at some point, as the owner decides to take the container images or Helm charts off the public registry, (2) Internet connectivity may not be available to the device and hence public registries are not reachable, or (3) end-users want to host their own registries so they can do security scans and validate the packages.
 
 In terms of connectivity, we can thereby distinguish mainly between the following device categories:
 
 1.	**Fully connected device**, which means a device is deployed in the field (e.g., a factory shop floor) and has access to the Internet.
 2.	**Locally connected device**, i.e., the device has connectivity to a local network (e.g., factory- or enterprise-wide) and a local repository can be made reachable.
 3.	**Air-gapped device**, i.e., the device generally is not connected and must be configured by accessing it directly (via USB, Bluetooth, or a direct network link, e.g., via Ethernet cable, or similar) for example via a technician’s laptop.
 
-Local registries for Docker images and Helm Charts can be used for all 3 categories of devices. In case of **fully connected devices**, although the device could reach the Internet, a local registry can still be useful, e.g., as a cache for remote registries to save on bandwidth or to have Docker images and Helm Carts reliably available. In case of **locally connected devices**, a local registry is required to enable the WOA to install margo applications on the device, as the device/WOA does not have Internet access. Thereby, the local registry can be setup as a _pull-through cache_ where data (e.g., Docker images) are cached locally when they are first retrieved from a remote source and subsequent requests for the same data are served from the local cache rather than fetching it again from the remote source. In case of **air-gapped devices**, a local registry has to be accessible on the technician's laptop (or other directly connected device), which performs the application installation process.
+Local registries for container images and Helm Charts can be used for all 3 categories of devices. In case of **fully connected devices**, although the device could reach the Internet, a local registry can still be useful, e.g., as a cache for remote registries to save on bandwidth or to have container images and Helm Carts reliably available. In case of **locally connected devices**, a local registry is required to enable the WOA to install margo applications on the device, as the device/WOA does not have Internet access. Thereby, the local registry can be setup as a _pull-through cache_ where data (e.g., container images) are cached locally when they are first retrieved from a remote source and subsequent requests for the same data are served from the local cache rather than fetching it again from the remote source. In case of **air-gapped devices**, a local registry has to be accessible on the technician's laptop (or other directly connected device), which performs the application installation process.
 
 To setup local registries, different configuration options exist:
 
-## Option - Docker Registry Mirror on Kubernetes Level
+## Option - Container Registry Mirror on Kubernetes Level
 
 Kubernetes supports the configuration of registry mirrors. How this is configured depends on the distribution and the underlying container runtime. Distributions that utilize **containerd** as runtime (e.g., k3s or microk8s) allow the definition of mirrors in a configuration file. For example, in k3s the file `/etc/rancher/k3s/registries.yaml` can be used to set up a mirror for each device's Kubernetes environment:
 
@@ -28,7 +28,7 @@ configs:
       password: "<password>"
 ```
 
-## Option - Docker Registry as Pull-through Cache on Docker Level
+## Option - Container Registry as Pull-through Cache on Docker Level
 
 To configure a pull-through cache in Docker for the container registry, a Docker Registry can be setup that acts as caching proxy for a remote Docker registry. Such a Docker Registry container can be defined using the following `config.yml`:
 

system-design/app-interoperability/workload-orch-to-app-reg-interaction.md

@@ -17,7 +17,7 @@ Then, the [application package](./application-package-definition.md) is ready to
 > **Note** 
 > The specifics of the installation process are still under discussion: this could be for example a GitOps based approach. 
 
-During this process the containers referenced in the application manifest ([Helm Chart](https://helm.sh/docs/) or [Docker Compose](https://github.com/compose-spec/compose-spec/blob/master/03-compose-file.md)) are retrieved from container/Helm registries. 
+During this process the containers referenced in the application manifest ([Helm Chart](https://helm.sh/docs/) or [Compose](https://github.com/compose-spec/compose-spec/blob/master/03-compose-file.md)) are retrieved from container/Helm registries. 
 
 At a minimum, a Margo-compliant WOS SHALL provide a way for an end user to manually setup a connection between the WOS and an application registry. This is required so as not to prohibit an end user for being able to install any Margo-compliant application they wish; including applications developed by the end user. 
 

system-design/margo-api-reference/workload-api/application-package-api/application-description.md

@@ -71,7 +71,7 @@ Represents a deployment configuration for the application. <br>
 
 | Attribute | Type | Required? | Description |
 | --- | --- | --- | --- |
-| type | string |  Y  | Indicates the components's deployment configuration.  The values are `helm.v3` to indicate the component's package format is Helm version 3  and `docker-compose` to indicate the component's package format is Docker Compose.  When installing the application on a device supporting the Kubernetes platform all `helm.v3` components,  and only `helm.v3` components, will be provided to the device in same order they are listed in the application description file.  When installing the application on a device supporting docker-compose all `docker-compose` components,  and only `docker-compose` components, will be provided to the device in the same order they are listed in the application description file.  The device will install the components in the same order they are listed in the application description file.|
+| type | string |  Y  | Indicates the component's deployment configuration. The values are `helm.v3` to indicate the component's package format is Helm version 3 and `compose` to indicate the component's package format is a Compose file. When installing the application on a device supporting the Kubernetes platform, all `helm.v3` components, and only `helm.v3` components, will be provided to the device in the same order they are listed in the application description file. When installing the application on a device supporting Compose, all `compose` components, and only `compose` components, will be provided to the device in the same order they are listed in the application description file. The device will install the components in the same order they are listed in the application description file.|
 | components | []Component |  Y  | Component element indicating the components to deploy when installing the application.  See the [Component](#component-attributes) section below.|
 
 
@@ -96,17 +96,15 @@ The expected properties for the suppported deployment types are indicated below.
 | wait | bool  | N  | If `True`, indicates the device MUST wait until the helm chart has finished installing before installing the next helm chart. The default is `True`. The Workload Orchestration Agent MUST support `True` and MAY support `False`. Only applies if multiple `helm.v3` components are provided.|
 | timeout | string      | N   | The time to wait for the component's installation to complete. If the installation does not completed before the timeout occurs the installation process fails. The format is "##m##s" indicating the total number of minutes and seconds to wait. |  
 
-- Properties for `docker-compose` components
+- Properties for `compose` components
 
-> **Investigation Needed**: We need to have more discussion about how docker-compose should be handled and what is required here.
-> We also need to determine if there is a version of docker-compose that needs to be specified. The docker compose schema [version has been
-> deprecated](https://github.com/compose-spec/compose-spec/blob/master/spec.md#version-and-name-top-level-elements) so it's not clear what we would even use for this if we wanted to.
+> **Investigation Needed**: We need to have more discussion about how Compose should be handled and what is required here.
 
 | Attribute      | Type  | Required?     | Description    |
 | --- | --- | --- | --- |
-| packageLocation  | string |  Y  | The URL indicating the Docker Compose package's location. |
+| packageLocation  | string |  Y  | The URL indicating the Compose package's location. |
 | keyLocation    | string | N  | The public key used to validated the digitally signed package. It is highly recommend to digitally sign the package. When signing the package PGP MUST be used.|
-| wait | bool  | N  | If `True`, indicates the device MUST wait until the Docker Compose file has finished starting up before starting the next Docker Compose file. The default is `True`. The Workload Orchestration Agent MUST support `True` and MAY support `False`. Only applies if multiple `docker-compose` components are provided.|
+| wait | bool  | N  | If `True`, indicates the device MUST wait until the Compose file has finished starting up before starting the next Compose file. The default is `True`. The Workload Orchestration Agent MUST support `True` and MAY support `False`. Only applies if multiple `compose` components are provided.|
 | timeout | string      | N   | The time to wait for the component's installation to complete. If the installation does not completed before the timeout occurs the installation process fails. The format is "##m##s" indicating the total number of minutes and seconds to wait.|
 
 ## Defining configurable application parameters
@@ -130,7 +128,7 @@ Specifies where the parameter applies in the deployment. <br>
 
 | Attribute | Type | Required? | Description |
 | --- | --- | --- | --- |
-| pointer | string |  Y  | The name of the parameter in the deployment configuration.  For Helm deployments, this is the dot notation for the matching element in the `values.yaml` file. This follows the same naming convention you would use with the `--set` command line argument with the `helm install` command.  For docker-compose deployments, this is the name of the environment variable to set.|
+| pointer | string |  Y  | The name of the parameter in the deployment configuration.  For Helm deployments, this is the dot notation for the matching element in the `values.yaml` file. This follows the same naming convention you would use with the `--set` command line argument with the `helm install` command.  For compose deployments, this is the name of the environment variable to set.|
 | components | []string |  Y  | Indicates which deployment profile [component](#component-attributes the parameter target applies to.  The component name specified here MUST match a component name in the [deployment profiles](#deploymentprofile-attributes) section.|
 
 
@@ -335,7 +333,7 @@ deploymentProfiles:
           repository: oci://northstarida.azurecr.io/charts/northstarida-digitron-orchestrator
           revision: 1.0.9
           wait: true
-  - type: docker-compose
+  - type: compose
     components:
       - name: digitron-orchestrator-docker
         properties: