Skip to content

Commit

Permalink
Add Documentation on using Debug Echo [SAME VERSION] (#296)
Browse files Browse the repository at this point in the history
  • Loading branch information
kate-goldenring authored Apr 9, 2021
1 parent 53903e7 commit cfca720
Show file tree
Hide file tree
Showing 3 changed files with 201 additions and 4 deletions.
157 changes: 157 additions & 0 deletions docs/debug-echo-configuration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,157 @@
# Debugging Akri using the Debug Echo Discovery Handler and Configuration
## Background
In order to kick start using and debugging Akri, a "debug echo" Discovery Handler has been created. The Discovery
Handler "discovers" all devices listed in the `descriptions` array in the `discoveryDetails` of a Debug Echo
configuration. Devices are visible to the Discovery Handler so long as the word "OFFLINE" does not exist in the file
`/tmp/debug-echo-availability.txt` in the Pod in which the Discovery Handler is running.

## Deploying the Debug Echo Discovery Handler
In order for the Agent to know how to discover Debug Echo devices, the Debug Echo 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 Debug Echo Discovery Handlers by specifying
`debugEcho.discovery.enabled=true` when installing Akri. Notes are provided for how the steps change if using embedded
Discovery Handlers.

Since the Debug Echo Discovery Handler is for debugging, it's use must be explicitly enabled by setting
`agent.allowDebugEcho=true`.

## Quickstart
### Installation
To install Akri with **external** Debug Echo Discovery Handlers and a Configuration to discover unshared Debug Echo
devices, run:
```bash
helm repo add akri-helm-charts https://deislabs.github.io/akri/
helm install akri akri-helm-charts/akri-dev \
--set agent.allowDebugEcho=true \
--set debugEcho.discovery.enabled=true \
--set debugEcho.configuration.enabled=true \
--set debugEcho.configuration.shared=false
```

> Note: To instead install Akri with Debug Echo Discovery Handlers **embedded** in the Agent, set `agent.full=true` and
> remove `debugEcho.discovery.enabled=true` like in the following installation:
>```bash
>helm repo add akri-helm-charts https://deislabs.github.io/akri/
>helm install akri akri-helm-charts/akri-dev \
> --set agent.allowDebugEcho=true \
> --set agent.full=true \
> --set debugEcho.configuration.enabled=true \
> --set debugEcho.configuration.shared=false
>```
By default, the Debug Echo Configuration discovers two devices, `foo1` and `foo2`, and automatically deploys an empty
nginx broker Pod to each discovered device, so you should see two instances and brokers created as a result of your
installation. By default, it also creates an Instance service for each device and a Configuration service for all
discovered devices. The Akri Agents, Controller, and (if using external Discovery Handlers) Debug Echo Discovery
Handlers should also be created.
```sh
watch kubectl get pods,akric,akrii,services -o wide
```
Set `debugEcho.configuration.shared=true` to discover Debug Echo devices that are shared by all nodes. For example, when
Akri is installed like above with `debugEcho.configuration.shared=false` onto a 3 node cluster. 6 Debug Echo devices
will be discovered and 6 Instances will be created, 2 for each Node. However, is `debugEcho.configuration.shared=true`
is set, only 2 will be discovered as it is mocking all 3 nodes "utilizing" the same two devices. Set
`debugEcho.configuration.capacity=3` to allow all 3 nodes to receive brokers to utilize each of the shared devices. It
defaults to `1`.

### Marking Devices "OFFLINE"
Debug Echo devices are "unplugged"/"disconnected" by writing `"OFFLINE"` into the `/tmp/debug-echo-availability.txt`
file inside the pod in which the Discovery Handler is running.

By default, Debug Echo Discovery Handlers run in their own Pods, so exec into each to mark the devices offline. For
single a single node cluster:
```sh
DEBUG_ECHO_DH_POD_NAME=$(kubectl get pods --selector=name=akri-debug-echo-discovery | grep akri | awk '{print $1}')
kubectl exec -i $DEBUG_ECHO_DH_POD_NAME -- /bin/bash -c "echo "OFFLINE" > /tmp/debug-echo-availability.txt"
```
>Note: `shared` devices have a 5 minute grace period before their instances are deleted, as they are more often network
>devices prone to intermittent connectivity.
>Note: For, multi-node clusters, each Agent or Debug Echo Discovery Handler must be `exec`ed into.
> Note: If `agent.full=true` was specified when installing Akri, the Debug Echo Discovery Handlers run inside the Agent,
> so exec into each Agent to mark the devices offline. For single a single node cluster:
> ```sh
> AGENT_POD_NAME=$(kubectl get pods --selector=name=akri-agent | grep akri | awk '{print $1}')
> kubectl exec -i $AGENT_POD_NAME -- /bin/bash -c "echo "OFFLINE" > /tmp/debug-echo-availability.txt"
> ```
Caveat: **Debug Echo devices likely should not be marked as shared for multi-node clusters**. This is because the
contents of `/tmp/debug-echo-availability.txt` could be different for each node. If one node marks a device as "OFFLINE"
but another does not, there is inconsistency around the existence of the device. However, this may be a scenario you
want to consider or test.
### Marking Devices "ONLINE"
Debug Echo devices are "plugged in"/"reconnected" by removing `"OFFLINE"` from the `/tmp/debug-echo-availability.txt`
file inside the pod in which the Discovery Handler is running. The commands below replace the file contents with
`"ONLINE"`.
By default, Debug Echo Discovery Handlers run in their own Pods, so exec into each to mark the devices offline. For
single a single node cluster:
```sh
DEBUG_ECHO_DH_POD_NAME=$(kubectl get pods --selector=name=akri-debug-echo-discovery | grep akri | awk '{print $1}')
kubectl exec -i $DEBUG_ECHO_DH_POD_NAME -- /bin/bash -c "echo "ONLINE" > /tmp/debug-echo-availability.txt"
```
>Note: For, multi-node clusters, each Agent or Debug Echo Discovery Handler must be `exec`ed into.
> Note: If `agent.full=true` was specified when installing Akri, the Debug Echo Discovery Handlers run inside the Agent,
> so exec into each Agent to mark the devices offline. For single a single node cluster:
> ```sh
> AGENT_POD_NAME=$(kubectl get pods --selector=name=akri-agent | grep akri | awk '{print $1}')
> kubectl exec -i $AGENT_POD_NAME -- /bin/bash -c "echo "ONLINE" > /tmp/debug-echo-availability.txt"
> ```
## In the Weeds: Debug Echo Configuration Settings
## Discovery Handler Discovery Details Settings
Discovery Handlers are passed discovery details that are set in a Configuration to determine what to discover, filter
out of discovery, and so on. The Debug Echo Discovery Handler simply "discovers" a device for each string in
`discoveryDetails.descriptions` in a Configuration.
| Helm Key | Value | Default | Description |
|---|---|---|---|
| debugEcho.configuration.discoveryDetails.description | array of arbitrary Strings | ["foo1", "foo2"] | Names for fake devices that will be discovered |
### Broker Pod Settings
By default, brokers are deployed to discovered Debug Echo devices. Set
`debugEcho.configuration.brokerPod.image.repository=""` to not deploy broker Pods. | Helm Key | Value | Default |
Description |
|---|---|---|---|
| debugEcho.configuration.brokerPod.image.repository | image string | nginx | image of broker Pod that should be
deployed to discovered devices | | debugEcho.configuration.brokerPod.image.tag | tag string | "latest" | image tag of
broker Pod that should be deployed to discovered devices |
### Disabling Automatic Service Creation
By default, if a broker Pod is specified, the Debug ECho Configuration will create services for all the brokers of a
specific Akri Instance and all the brokers of an Akri Configuration. The creation of these services can be disabled. |
Helm Key | Value | Default | Description |
|---|---|---|---|
| debugEcho.configuration.createInstanceServices | true, false | true | a service should be automatically created for
each broker Pod | | debugEcho.configuration.createConfigurationService | true, false | true | a single service should be
created for all brokers of a Configuration |
### Capacity Setting
By default, if a broker Pod is specified, a single broker Pod is deployed to each device. To modify the Configuration so
that an OPC UA server is accessed by more or fewer nodes via broker Pods, update the `debugEcho.configuration.capacity`
setting to reflect the correct number. For example, if your high availability needs are met by having 1 redundant pod,
you can update the Configuration like this by setting `debugEcho.configuration.capacity=2`. | Helm Key | Value | Default
| Description |
|---|---|---|---|
| debugEcho.configuration.capacity | number | 1 | maximum number of brokers that can be deployed to utilize a device (up
to 1 per Node) |
## Modifying a Configuration
Akri has provided further documentation on [modifying the broker
PodSpec](./customizing-akri-installation.md#modifying-the-brokerpodspec), [instanceServiceSpec, or
configurationServiceSpec](./customizing-akri-installation.md#modifying-instanceservicespec-or-configurationservicespec)
More information about how to modify an installed Configuration, add additional Configurations to a cluster, or delete a
Configuration can be found in the [Customizing an Akri Installation document](./customizing-akri-installation.md).
## Implementation details
The DebugEcho implementation can be understood by looking at its [Discovery
Handler](../discovery-handlers/debug-echo/src/discovery_handler.rs), which contains the `DebugEchoDiscoveryDetails`
struct, which describes the expected format of a Configuration's `DiscoveryDetails`.
46 changes: 43 additions & 3 deletions docs/development.md
Original file line number Diff line number Diff line change
Expand Up @@ -50,9 +50,45 @@ There are unit tests for all of the Rust code. To run all unit tests, simply na

To locally run the controller as part of a k8s cluster, follow these steps:

1. Create or provide access to a valid cluster configuration by setting KUBECONFIG (can be done in the commandline) ... for the sake of this, the config is assumed to be in ~/test.cluster.config
1. Build the repo by running `cargo build`
1. Run the desired component (in this case, looking at info-level logging and running the controller locally): `RUST_LOG=info KUBECONFIG=~/test.cluster.config ./target/debug/controller`
1. Create or provide access to a valid cluster configuration by setting KUBECONFIG (can be done in the commandline) ...
for the sake of this, the config is assumed to be in ~/test.cluster.config
1. Build the repo with all default features by running `cargo build`
> Note: By default, the Agent does not have embedded Discovery Handlers. To allow embedded Discovery Handlers in the
> Agent, turn on the `agent-full` feature and the feature for each Discovery Handler you wish to embed -- Debug echo
> is always included if `agent-full` is turned on. For example, to build an Agent with OPC UA, ONVIF, udev, and
> debug echo Discovery Handlers: `cargo build --manifest-path agent/Cargo.toml --features "agent-full udev-feat
> opcua-feat onvif-feat"`.
1. Run the desired component

Run the **Controller** locally with info-level logging: `RUST_LOG=info KUBECONFIG=~/test.cluster.config
./target/debug/controller`

Run the **Agent** locally with info-level logging:
```sh
sudo DEBUG_ECHO_INSTANCES_SHARED=true ENABLE_DEBUG_ECHO=1 RUST_LOG=info KUBECONFIG=~/test.cluster.config DISCOVERY_HANDLERS_DIRECTORY=~/tmp/akri AGENT_NODE_NAME=myNode HOST_CRICTL_PATH=/usr/bin/crictl HOST_RUNTIME_ENDPOINT=/var/run/dockershim.sock HOST_IMAGE_ENDPOINT=/var/run/dockershim.sock ./target/debug/agent
```
> Note: The environment variables `HOST_CRICTL_PATH`, `HOST_RUNTIME_ENDPOINT`, and `HOST_IMAGE_ENDPOINT` are for
> slot-reconciliation (making sure Pods that no longer exist are not still claiming Akri resources). The values of
> these vary based on Kubernetes distribution. The above is for vanilla Kubernetes. For MicroK8s, use
> `HOST_CRICTL_PATH=/usr/local/bin/crictl HOST_RUNTIME_ENDPOINT=/var/snap/microk8s/common/run/containerd.sock
> HOST_IMAGE_ENDPOINT=/var/snap/microk8s/common/run/containerd.sock` and for K3s, use
> `HOST_CRICTL_PATH=/usr/local/bin/crictl HOST_RUNTIME_ENDPOINT=/run/k3s/containerd/containerd.sock
> HOST_IMAGE_ENDPOINT=/run/k3s/containerd/containerd.sock`.

To run **Discovery Handlers** locally, simply navigate to the Discovery Handler under
`akri/discovery-handler-modules/` and run using cargo run, setting where the Discovery Handler socket should be
created in the `DISCOVERY_HANDLERS_DIRECTORY` variable. For example, to run the ONVIF Discovery Handler locally:
```sh
cd akri/discovery-handler-modules/onvif-discovery-handler/
RUST_LOG=info DISCOVERY_HANDLERS_DIRECTORY=~/tmp/akri AGENT_NODE_NAME=myNode cargo run
```
To run the [debug echo Discovery Handler](#testing-with-debug-echo-discovery-handler), an environment variable,
`DEBUG_ECHO_INSTANCES_SHARED`, must be set to specify whether it should register with the Agent as discovering
shared or unshared devices. Run the debug echo Discovery Handler to discover mock unshared devices like so:
```sh
cd akri/discovery-handler-modules/debug-echo-discovery-handler/
RUST_LOG=info DEBUG_ECHO_INSTANCES_SHARED=false DISCOVERY_HANDLERS_DIRECTORY=~/tmp/akri AGENT_NODE_NAME=myNode cargo run
```

### To build containers
`Makefile` has been created to help with the more complicated task of building the Akri components and containers for the various supported platforms.
Expand Down Expand Up @@ -184,6 +220,10 @@ helm get manifest akri | less
### Helm Upgrade
To modify an Akri installation to reflect a new state, you can use [`helm upgrade`](https://helm.sh/docs/helm/helm_upgrade/). See the [Customizing an Akri Installation document](./customizing-akri-installation.md) for further explanation.

## Testing with Debug Echo Discovery Handler
In order to kickstart using and debugging Akri, a debug echo Discovery Handler has been created. See its
[documentation](./debug-echo-configuration.md) to start using it.

## Naming Guidelines

One of the [two hard things](https://martinfowler.com/bliki/TwoHardThings.html) in Computer Science is naming things. It is proposed that Akri adopt naming guidelines to make developers' lives easier by providing consistency and reduce naming complexity.
Expand Down
2 changes: 1 addition & 1 deletion docs/opcua-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ OPC UA servers registered with it.
| opcua.configuration.discoveryDetails.applicationNames.items | array of application names | empty | application names that the filter action acts upon |

### Broker Pod Settings
If you would like workloads ("broker" Pods) to be deployed automatically to discovered cameras, a broker image should be specified in the Configuration. Alternatively, if it meets your scenario, you could use the Akri frame server broker ("ghcr.io/deislabs/akri/opcua-video-broker"). If you would rather manually deploy pods to utilize the cameras advertized by Akri, don't specify a broker pod and see our documentation on [requesting resources advertized by Akri](./requesting-akri-resources.md).
If you would like workloads ("broker" Pods) to be deployed automatically to discovered devices, a broker image should be specified in the Configuration. Alternatively, if it meets your scenario, you could use the Akri frame server broker ("ghcr.io/deislabs/akri/opcua-video-broker"). If you would rather manually deploy pods to utilize the devices advertized by Akri, don't specify a broker pod and see our documentation on [requesting resources advertized by Akri](./requesting-akri-resources.md).
| Helm Key | Value | Default | Description |
|---|---|---|---|
| opcua.configuration.brokerPod.image.repository | image string | "" | image of broker Pod that should be deployed to discovered devices |
Expand Down

0 comments on commit cfca720

Please sign in to comment.