margo
diff --git a/‎src/margo-api-reference/workload-api/application-package-api/resources/index.md.jinja2‎
Lines changed: 2 additions & 2 deletions b/‎src/margo-api-reference/workload-api/application-package-api/resources/index.md.jinja2‎
Lines changed: 2 additions & 2 deletions
diff --git a/‎system-design/device-interoperability/collecting-workload-observability-data.md‎
Lines changed: 6 additions & 6 deletions b/‎system-design/device-interoperability/collecting-workload-observability-data.md‎
Lines changed: 6 additions & 6 deletions
diff --git a/‎system-design/device-interoperability/device-requirements.md‎
Lines changed: 6 additions & 6 deletions b/‎system-design/device-interoperability/device-requirements.md‎
Lines changed: 6 additions & 6 deletions
@@ -71,7 +71,7 @@ The expected properties for the suppported deployment types are indicated below.
 | --- | --- | --- | --- |
 | repository     | string |  Y  | The URL indicating the helm chart's location.|
 | revision      | string |  Y  | The helm chart's full version.|
-| 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.|
+| 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 Fleet Management Client 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 `compose` components
@@ -82,7 +82,7 @@ The expected properties for the suppported deployment types are indicated below.
 | --- | --- | --- | --- |
 | 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 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.|
+| 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 Fleet Management Client 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
 
@@ -82,15 +82,15 @@ For devices running non-clustered container platforms such as Docker or Podman t
 
   > **Note:** Please see the [information below](#workload-observability-default-telemetry) for the default metrics emitted by the Host Metrics Receivers.
 
-## Workload Fleet Management Agent Observability Requirements
+## Workload Fleet Management Client Observability Requirements
 
-For several reasons, it is recommended the workload fleet management agent be deployed as a containerized workload. If it is deployed this way, the workload's resource utilization observability data is captured automatically as part of the container platform observability requirements.
+For several reasons, it is recommended the Workload Fleet Management Client be deployed as a containerized workload. If it is deployed this way, the workload's resource utilization observability data is captured automatically as part of the container platform observability requirements.
 
-If the device owner chooses not to deploy the workload fleet management agent as a containerized workload they MUST ensure the following resource usage observability data is available from the OpenTelemetry collector for their agent.
+If the device owner chooses not to deploy the Workload Fleet Management Client as a containerized workload they MUST ensure the following resource usage observability data is available from the OpenTelemetry collector for their client.
 
-> **Action:** Need to do research to determine if this makes sense, or not, when the agent is not running as a containerized workload. We may have to leave it up to what is covered through device observability for this case. If it is possible, and makes sense, we need to define what should be provided.
+> **Action:** Need to do research to determine if this makes sense, or not, when the client is not running as a containerized workload. We may have to leave it up to what is covered through device observability for this case. If it is possible, and makes sense, we need to define what should be provided.
 
-In addition to the resource utilization data the workload fleet management agent MUST also send the following minimum set of workload observability data to the open telemetry collector on the standalone device or cluster. The device owner MAY choose to provided additional observability data if they wish.
+In addition to the resource utilization data the Workload Fleet Management Client MUST also send the following minimum set of workload observability data to the open telemetry collector on the standalone device or cluster. The device owner MAY choose to provided additional observability data if they wish.
 
 > **Action:** We need to understand what the WOS/a is going to be doing to determine what this is.
 
@@ -114,7 +114,7 @@ End users MUST be able to export observability data from a standalone device or
 > **Decision Needed:** There is a dependency on the decisions about using OpenTelemetry instead of the management API approach. If OpenTelemetry is chosen then there would be some subset of data that MUST be exported to the workload fleet manager supplier.
 >
 > **Future Decision:**
-> For MVS1 we have decided the configuration is updated manually. We know this is not ideal because it is error prone and can result in changes being made that should not be made. The current thinking is that the device fleet management agent will be responsible for updating the configuration when the WOS vendor or customer needs to add exports but this is out of scope for MVS1.
+> For MVS1 we have decided the configuration is updated manually. We know this is not ideal because it is error prone and can result in changes being made that should not be made. The current thinking is that the Device Fleet Management Client will be responsible for updating the configuration when the WOS vendor or customer needs to add exports but this is out of scope for MVS1.
 
 OpenTelemetry allows using either a push or pull approach for getting data from a collector. Cloud based workload fleet management or observability platform service vendors should NOT require a pull method for collecting observability data because most end users will not allow devices to be exposed to the internet because of security concerns.
 
 
@@ -24,15 +24,15 @@ The Cluster Leader Role within Margo describes devices that have the ability to
 
 **Cluster Leader Functional Requirements:**
 
-- Host the "Workload Fleet Management Agent" Interface
+- Host the Workload Fleet Management Client
     - This enables the device with the functionality outlined within the [Workload Management](../margo-overview/workload-management-interface-overview.md) section of the specification
 - Enable management functionality via Kubernetes API
 - Host the following additional components:
     - Helm Client (Provider)
     - OCI Container Runtime
     - OTEL Collector
     - Policy Agent
-    - Host Device Fleet Management Agent
+    - Host Device Fleet Management Client
         - > Note: this functionality is coming soon to the specification
 
 ## Cluster Worker Role Details
@@ -46,7 +46,7 @@ The Cluster Worker Role within Margo describes devices that have a limited amoun
     - OCI Container Runtime
     - OTEL Collector
     - Policy Agent
-    - Host Device Fleet Management Agent
+    - Host Device Fleet Management Client
         - > Note: this functionality is coming soon to the specification
 
 ## Standalone Cluster Role Details
@@ -65,11 +65,11 @@ The Standalone Device role represents a device that can host Margo Compliant Wor
 
 **Standalone Device functional requirements:**
 
-- Host the "Workload Fleet Management Agent" Interface
+- Host the Workload Fleet Management Client
     - This enables the device with the functionality outlined within the [Workload Management](../margo-overview/workload-management-interface-overview.md) section of the specification
 - Host the following additional components:
     - OCI Container Runtime
     - OTEL Collector
     - Policy Agent
-    - Host Device Fleet Management Agent
-        - **Note:** Out of scope for MVS1
+    - Host Device Fleet Management Client
+        - > Note: this functionality is coming soon to the specification