Rename configuration templates (#315)

* rename configuration templates * increase version
project-akri · Apr 22, 2021 · 2679410 · 2679410
1 parent 1738ef1
commit 2679410
Show file tree

Hide file tree

Showing 35 changed files with 46 additions and 46 deletions.
diff --git a/Cargo.lock b/Cargo.lock
diff --git a/agent/Cargo.toml b/agent/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "agent"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>", "<bfjelds@microsoft.com>"]
 edition = "2018"
 

diff --git a/controller/Cargo.toml b/controller/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "controller"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["<bfjelds@microsoft.com>"]
 edition = "2018"
 

diff --git a/deployment/helm/Chart.yaml b/deployment/helm/Chart.yaml
@@ -15,9 +15,9 @@ type: application
 # This is the chart version. This version number should be incremented each time you make changes
 # to the chart and its templates, including the app version.
 # Versions are expected to follow Semantic Versioning (https://semver.org/)
-version: 0.6.2
+version: 0.6.3
 
 # This is the version number of the application being deployed. This version number should be
 # incremented each time you make changes to the application. Versions are not expected to
 # follow Semantic Versioning. They should reflect the version the application is using.
-appVersion: 0.6.2
+appVersion: 0.6.3
diff --git a/deployment/helm/templates/custom.yaml → .../helm/templates/custom-configuration.yaml b/deployment/helm/templates/custom.yaml → .../helm/templates/custom-configuration.yaml
diff --git a/deployment/helm/templates/debug-echo.yaml → ...m/templates/debug-echo-configuration.yaml b/deployment/helm/templates/debug-echo.yaml → ...m/templates/debug-echo-configuration.yaml
diff --git a/deployment/helm/templates/onvif.yaml → ...t/helm/templates/onvif-configuration.yaml b/deployment/helm/templates/onvif.yaml → ...t/helm/templates/onvif-configuration.yaml
diff --git a/deployment/helm/templates/opcua.yaml → ...t/helm/templates/opcua-configuration.yaml b/deployment/helm/templates/opcua.yaml → ...t/helm/templates/opcua-configuration.yaml
diff --git a/deployment/helm/templates/udev.yaml → ...nt/helm/templates/udev-configuration.yaml b/deployment/helm/templates/udev.yaml → ...nt/helm/templates/udev-configuration.yaml
diff --git a/deployment/helm/values.yaml b/deployment/helm/values.yaml
@@ -233,7 +233,7 @@ debugEcho:
       # repository is the container reference
       repository: ghcr.io/deislabs/akri/debug-echo-discovery
       # tag is the container tag
-      # debugEcho.yaml will default to v(AppVersion)[-dev]
+      # debug-echo-configuration.yaml will default to v(AppVersion)[-dev]
       # with `-dev` added if `useDevelopmentContainers` is specified
       tag:
       # pullPolicy is the pull policy
@@ -320,7 +320,7 @@ onvif:
       # repository is the container reference
       repository: ghcr.io/deislabs/akri/onvif-discovery
       # tag is the container tag
-      # onvif.yaml will default to v(AppVersion)[-dev]
+      # onvif-configuration.yaml will default to v(AppVersion)[-dev]
       # with `-dev` added if `useDevelopmentContainers` is specified
       tag:
       # pullPolicy is the pull policy
@@ -405,7 +405,7 @@ opcua:
       # repository is the container reference
       repository: ghcr.io/deislabs/akri/opcua-discovery
       # tag is the container tag
-      # opcua.yaml will default to v(AppVersion)[-dev]
+      # opcua-configuration.yaml will default to v(AppVersion)[-dev]
       # with `-dev` added if `useDevelopmentContainers` is specified
       tag:
       # pullPolicy is the pull policy
@@ -482,7 +482,7 @@ udev:
       # repository is the container reference
       repository: ghcr.io/deislabs/akri/udev-discovery
       # tag is the container tag
-      # udev.yaml will default to v(AppVersion)[-dev]
+      # udev-configuration.yaml will default to v(AppVersion)[-dev]
       # with `-dev` added if `useDevelopmentContainers` is specified
       tag:
       # pullPolicy is the pull policy

diff --git a/discovery-handler-modules/debug-echo-discovery-handler/Cargo.toml b/discovery-handler-modules/debug-echo-discovery-handler/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "debug-echo-discovery-handler"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>"]
 edition = "2018"
 

diff --git a/discovery-handler-modules/onvif-discovery-handler/Cargo.toml b/discovery-handler-modules/onvif-discovery-handler/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "onvif-discovery-handler"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>"]
 edition = "2018"
 

diff --git a/discovery-handler-modules/opcua-discovery-handler/Cargo.toml b/discovery-handler-modules/opcua-discovery-handler/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "opcua-discovery-handler"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>"]
 edition = "2018"
 

diff --git a/discovery-handler-modules/udev-discovery-handler/Cargo.toml b/discovery-handler-modules/udev-discovery-handler/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "udev-discovery-handler"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>"]
 edition = "2018"
 

diff --git a/discovery-handlers/debug-echo/Cargo.toml b/discovery-handlers/debug-echo/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "akri-debug-echo"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>"]
 edition = "2018"
 

diff --git a/discovery-handlers/onvif/Cargo.toml b/discovery-handlers/onvif/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "akri-onvif"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>"]
 edition = "2018"
 

diff --git a/discovery-handlers/opcua/Cargo.toml b/discovery-handlers/opcua/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "akri-opcua"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>"]
 edition = "2018"
 

diff --git a/discovery-handlers/udev/Cargo.toml b/discovery-handlers/udev/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "akri-udev"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>"]
 edition = "2018"
 

diff --git a/discovery-utils/Cargo.toml b/discovery-utils/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "akri-discovery-utils"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>"]
 edition = "2018"
 

diff --git a/docs/architecture.md b/docs/architecture.md
@@ -15,7 +15,7 @@ The configuration of Akri is enabled by the Configuration CRD.  Akri users will
 * a ServiceSpec (spec.instanceServiceSpec) that defines the service that provides a single stable endpoint to access each individual resource's set of broker pods.
 * a ServiceSpec (spec.configurationServiceSpec) that defines the service that provides a single stable endpoint to access the set of all brokers for all resources associated with the Configuration.
 
-Akri has already provided two Configurations, one for discovering IP cameras using the ONVIF protocol and the other for discovering USB cameras via udev. Let's look at an [example ONVIF Configuration yaml](../test/yaml/akri-onvif-video.yaml). You can see it specifies the protocol ONVIF, an image for the broker pod, a capacity of 5, and two Kubernetes services. In this case, the broker pod is a sample frame server we have provided. To get only the frames from a specific camera, a user could point an application at the Instance service, while the Configuration service provides the frames from all the cameras.The ONVIF Configuration can be customized using Helm. When installing the ONVIF Configuration to your Akri enabled cluster, you can specify [the values](../deployment/helm/values.yaml) you want to be inserted into the [ONVIF Configuration template](../deployment/helm/templates/onvif.yaml). Learn more about [deploying the ONVIF sample here](./onvif-configuration.md). 
+Akri has already provided two Configurations, one for discovering IP cameras using the ONVIF protocol and the other for discovering USB cameras via udev. Let's look at an [example ONVIF Configuration yaml](../test/yaml/akri-onvif-video-configuration.yaml). You can see it specifies the protocol ONVIF, an image for the broker pod, a capacity of 5, and two Kubernetes services. In this case, the broker pod is a sample frame server we have provided. To get only the frames from a specific camera, a user could point an application at the Instance service, while the Configuration service provides the frames from all the cameras.The ONVIF Configuration can be customized using Helm. When installing the ONVIF Configuration to your Akri enabled cluster, you can specify [the values](../deployment/helm/values.yaml) you want to be inserted into the [ONVIF Configuration template](../deployment/helm/templates/onvif-configuration.yaml). Learn more about [deploying the ONVIF sample here](./onvif-configuration.md). 
 
 ### Akri Instance CRD
 Each Instance represents an individual resource that is visible to the cluster. So, if there are 5 IP cameras visible to the cluster, there will be 5 Instances. Akri coordination and resource sharing is enabled by the Instance CRD. These instances store internal Akri state and are not intended to be edited by users. For a more in-depth understanding on how resource sharing is accomplished, see [Resource Sharing In-depth](./resource-sharing-in-depth.md).

diff --git a/docs/end-to-end-demo-rpi4.md b/docs/end-to-end-demo-rpi4.md
@@ -98,7 +98,7 @@ You tell Akri what you want to find with an Akri Configuration, which is one of
 
 For this demo, we will specify (1) Akri's udev Discovery Handler, which is used to discover devices in the Linux device file system. Akri's udev Discovery Handler supports (2) filtering by udev rules. We want to find all video devices in the Linux device file system, which can be specified with the udev rule `KERNEL=="video[0-9]*"`. Say we wanted to be more specific and only discover devices made by Great Vendor, we could adjust our rule to be `KERNEL=="video[0-9]*"\, ENV{ID_VENDOR}=="Great Vendor"`. For (3) a broker Pod image, we will use a sample container that Akri has provided that pulls frames from the cameras and serves them over gRPC. 
 
-All of Akri's components can be deployed by specifying values in its Helm chart during an installation. Instead of having to build a Configuration from scratch, Akri has provided [Helm templates](../deployment/helm/templates) for Configurations for each supported Discovery Handler. Lets customize the generic [udev Configuration Helm template](../deployment/helm/templates/udev.yaml) with our three specifications above. We can also set the name for the Configuration to be `akri-udev-video`.
+All of Akri's components can be deployed by specifying values in its Helm chart during an installation. Instead of having to build a Configuration from scratch, Akri has provided [Helm templates](../deployment/helm/templates) for Configurations for each supported Discovery Handler. Lets customize the generic [udev Configuration Helm template](../deployment/helm/templates/udev-configuration.yaml) with our three specifications above. We can also set the name for the Configuration to be `akri-udev-video`.
 
 In order for the Agent to know how to discover video devices, the udev Discovery Handler must exist. Akri supports an Agent image that includes all supported Discovery Handlers. This Agent will be used if `agent.full=true` is set. By default, a slim Agent without any embedded Discovery Handlers is deployed and the required Discovery Handlers can be deployed as DaemonSets. This demo will use that strategy, deploying the udev Discovery Handlers by specifying `udev.discovery.enabled=true` when installing Akri.
 

diff --git a/docs/end-to-end-demo.md b/docs/end-to-end-demo.md
@@ -81,7 +81,7 @@ You tell Akri what you want to find with an Akri Configuration, which is one of
 
 For this demo, we will specify (1) Akri's udev Discovery Handler, which is used to discover devices in the Linux device file system. Akri's udev Discovery Handler supports (2) filtering by udev rules. We want to find all video devices in the Linux device file system, which can be specified with the udev rule `KERNEL=="video[0-9]*"`. Say we wanted to be more specific and only discover devices made by Great Vendor, we could adjust our rule to be `KERNEL=="video[0-9]*"\, ENV{ID_VENDOR}=="Great Vendor"`. For (3) a broker Pod image, we will use a sample container that Akri has provided that pulls frames from the cameras and serves them over gRPC. 
 
-All of Akri's components can be deployed by specifying values in its Helm chart during an installation. Instead of having to build a Configuration from scratch, Akri has provided [Helm templates](../deployment/helm/templates) for Configurations for each supported Discovery Handler. Lets customize the generic [udev Configuration Helm template](../deployment/helm/templates/udev.yaml) with our three specifications above. We can also set the name for the Configuration to be `akri-udev-video`. Also, if using MicroK8s or K3s, configure the crictl path and socket using the `AKRI_HELM_CRICTL_CONFIGURATION` variable created when setting up your cluster. 
+All of Akri's components can be deployed by specifying values in its Helm chart during an installation. Instead of having to build a Configuration from scratch, Akri has provided [Helm templates](../deployment/helm/templates) for Configurations for each supported Discovery Handler. Lets customize the generic [udev Configuration Helm template](../deployment/helm/templates/udev-configuration.yaml) with our three specifications above. We can also set the name for the Configuration to be `akri-udev-video`. Also, if using MicroK8s or K3s, configure the crictl path and socket using the `AKRI_HELM_CRICTL_CONFIGURATION` variable created when setting up your cluster. 
 
 In order for the Agent to know how to discover video devices, the udev Discovery Handler must exist. Akri supports an Agent image that includes all supported Discovery Handlers. This Agent will be used if `agent.full=true` is set. By default, a slim Agent without any embedded Discovery Handlers is deployed and the required Discovery Handlers can be deployed as DaemonSets. This demo will use that strategy, deploying the udev Discovery Handlers by specifying `udev.discovery.enabled=true` when installing Akri.
 

diff --git a/docs/onvif-configuration.md b/docs/onvif-configuration.md
@@ -15,7 +15,7 @@ All of Akri's components can be deployed by specifying values in its Helm chart
 In order for the Agent to know how to discover IP cameras an ONVIF Discovery Handler must exist. Akri supports an Agent image that includes all supported Discovery Handlers. This Agent will be used if `agent.full=true`. By default, a slim Agent without any embedded Discovery Handlers is deployed and the required Discovery Handlers can be deployed as DaemonSets. This documentation will use that strategy, deploying ONVIF Discovery Handlers by specifying `onvif.discovery.enabled=true` when installing Akri.
 ## ONVIF Configuration Settings
 Instead of having to assemble your own ONVIF Configuration yaml, we have provided a [Helm
-template](../deployment/helm/templates/onvif.yaml). Helm allows us to parametrize the commonly modified fields in our configuration files, and we have provided many for ONVIF (to see
+template](../deployment/helm/templates/onvif-configuration.yaml). Helm allows us to parametrize the commonly modified fields in our configuration files, and we have provided many for ONVIF (to see
 them, run `helm inspect values akri-helm-charts/akri`). More information about the Akri Helm charts can be found in the [user guide](./user-guide.md#understanding-akri-helm-charts).
 To apply the ONVIF Configuration to your cluster, simply set `onvif.configuration.enabled=true` along with any of the following additional Configuration settings when installing Akri.
 ### Discovery Handler Discovery Details Settings

diff --git a/docs/opcua-configuration.md b/docs/opcua-configuration.md
@@ -9,7 +9,7 @@ In order for the Agent to know how to discover OPC UA servers an OPC UA Discover
 
 ## OPC UA Configuration Settings
 Instead of having to assemble your own OPC UA Configuration yaml, we have provided a [Helm
-template](../deployment/helm/templates/opcua.yaml). Helm allows us to parametrize the commonly modified fields in our configuration files, and we have provided many for OPC UA (to see
+template](../deployment/helm/templates/opcua-configuration.yaml). Helm allows us to parametrize the commonly modified fields in our configuration files, and we have provided many for OPC UA (to see
 them, run `helm inspect values akri-helm-charts/akri`). More information about the Akri Helm charts can be found in the [user guide](./user-guide.md#understanding-akri-helm-charts).
 To apply the OPC UA Configuration to your cluster, simply set `opcua.configuration.enabled=true` along with any of the following additional Configuration settings when installing Akri.
 ### Discovery Handler Discovery Details Settings

diff --git a/docs/opcua-demo.md b/docs/opcua-demo.md
@@ -101,7 +101,7 @@ kubectl create secret generic opcua-broker-credentials \
 When mounting certificates is enabled later in the [Running Akri section](#running-akri) with Helm via `--set
 opcua.mountCertificates='true'`, the secret named `opcua-broker-credentials` will be mounted into the OPC UA monitoring
 brokers. It is mounted to the volume `credentials` at the `mountPath` /etc/opcua-certs/client-pki, as shown in the [OPC
-UA Configuration Helm template](../deployment/helm/templates/opcua.yaml). This is the path where the brokers expect to
+UA Configuration Helm template](../deployment/helm/templates/opcua-configuration.yaml). This is the path where the brokers expect to
 find the certificates.
 
 ## Creating OPC UA Servers

diff --git a/samples/brokers/udev-video-broker/Cargo.toml b/samples/brokers/udev-video-broker/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "udev-video-broker"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["Kate Goldenring <kate.goldenring@microsoft.com>", "<bfjelds@microsoft.com>"]
 edition = "2018"
 

diff --git a/shared/Cargo.toml b/shared/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "akri-shared"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["<bfjelds@microsoft.com>"]
 edition = "2018"
 

diff --git a/shared/src/akri/configuration.rs b/shared/src/akri/configuration.rs
@@ -252,10 +252,10 @@ mod crd_serialization_tests {
         let _ = env_logger::builder().is_test(true).try_init();
 
         let files = [
-            "../test/yaml/akri-onvif-video.yaml",
-            "../test/yaml/akri-debug-echo-foo.yaml",
-            "../test/yaml/akri-udev-video.yaml",
-            "../test/yaml/akri-opcua.yaml",
+            "../test/yaml/akri-onvif-video-configuration.yaml",
+            "../test/yaml/akri-debug-echo-foo-configuration.yaml",
+            "../test/yaml/akri-udev-video-configuration.yaml",
+            "../test/yaml/akri-opcua-configuration.yaml",
         ];
         for file in &files {
             log::trace!("test file: {}", &file);

diff --git a/test/run-webhook.md b/test/run-webhook.md
@@ -2,7 +2,7 @@
 
 File: `/tests/run-webhook.py`
 
-Complements existing Python-based end-to-end test [script](/test/run-end-to-end.py) with a script to test Akri configured to use the Configuration Admission Controller Webhook ([README](/webhooks/validating/configuration/README.me)).
+Complements existing Python-based end-to-end test [script](/test/run-end-to-end.py) with a script to test Akri configured to use the Configuration Admission Controller Webhook ([README](/webhooks/validating/configuration/README.md)).
 
 The Webhook validates Akri Configurations, permitting (semantically) valid Configurations to be applied to a cluster and prohibiting (semantically) invalid Configurations.
 

diff --git a/test/yaml/akri-debug-echo-foo.yaml → ...ml/akri-debug-echo-foo-configuration.yaml b/test/yaml/akri-debug-echo-foo.yaml → ...ml/akri-debug-echo-foo-configuration.yaml
diff --git a/test/yaml/akri-onvif-video.yaml → .../yaml/akri-onvif-video-configuration.yaml b/test/yaml/akri-onvif-video.yaml → .../yaml/akri-onvif-video-configuration.yaml
diff --git a/test/yaml/akri-opcua.yaml → test/yaml/akri-opcua-configuration.yaml b/test/yaml/akri-opcua.yaml → test/yaml/akri-opcua-configuration.yaml
diff --git a/test/yaml/akri-udev-video.yaml → test/yaml/akri-udev-video-configuration.yaml b/test/yaml/akri-udev-video.yaml → test/yaml/akri-udev-video-configuration.yaml
diff --git a/version.txt b/version.txt
@@ -1 +1 @@
-0.6.2
+0.6.3
diff --git a/webhooks/validating/configuration/Cargo.toml b/webhooks/validating/configuration/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "webhook-configuration"
-version = "0.6.2"
+version = "0.6.3"
 authors = ["DazWilkin <daz.wilkin@gmail.com>"]
 edition = "2018"