DiscoveryHandler
service and Registration
client defined in the Akri's discovery gRPC proto file. These DHs run as their own Pods and are expected to register with the Agent, which hosts the Registration
service defined in the gRPC interface.DiscoveryHandler
service/var/lib/akri/agent-registration.sock
. The directory can be changed when installing Akri by setting agent.host.discoveryHandlers
. For example, to request that the Agent's Registration
service live at ~/akri/sockets/agent-registration.sock
set agent.host.discoveryHandlers=~/akri/sockets
when installing Akri. The Agent hosts the Registration
service defined in Akri's discovery interface on this socket.EndpointType
of either UDS
or Network
in the RegisterDiscoveryHandlerRequest
. While Discovery Handlers must register with the Agent's Registration
service over UDS, a DiscoveryHandler
service can run over UDS or an IP based endpoint. However, the current convention is to use UDS for both registration and discovery.discoveryDetails
. Akri's Configuration CRD takes in DiscoveryHandlerInfo
, which is defined structurally in Rust as follows:discovery_details
string. The Agent passes this string to Discovery Handlers as part of a DiscoverRequest
. A Discovery Handler must then parse this string -- Akri's built in Discovery Handlers store an expected structure in it as serialized YAML -- to determine what to discover, filter out of discovery, and so on.discoveryHandler.name
must match RegisterDiscoveryHandlerRequest.name
the Discovery Handler uses when registering with the Agent. Once you know what will be passed to your Discovery Handler, its time to implement the discovery functionality.DiscoveryHandler
serviceDevice
type, as shown in a subset of the discovery proto file below. A Discovery Handler sets a unique id
for the device, device connection information that needs to be set as environment variables in Pods that request the device in properties
, and any mounts or devices that should be available to requesting Pods.discover
creates a streamed connection with the Agent, where the Agent gets the receiving end of the channel and the Discovery Handler sends device updates via the sending end of the channel. If the Agent drops its end, the Discovery Handler should stop discovery and attempt to re-register with the Agent. The Agent may drop its end due to an error or a deleted Configuration.cargo-generate
.cargo-generate
and use the tool to pull down Akri's template, specifying the name of the project with the --name
parameter.akri-discovery-handler
project, navigate to main.rs
. It contains all the logic to register our DiscoveryHandler
with the Akri Agent. We only need to specify the DiscoveryHandler
name and whether the devices discovered by our DiscoveryHandler
can be shared. This is the name the Discovery Handler uses when registering with the Agent. It is later specified in a Configuration to tell the Agent which Discovery Handler to use. For example, in Akri's udev Discovery Handler, name
is set to udev
and shared
to false
as all devices are locally attached to nodes. The Discovery Handler name also resolves to the name of the socket the template serves the Discovery Handler on.DiscoveryHandlerImpl
Struct has been created (in discovery_handler.rs
) that minimally implements the DiscoveryHandler
service. Fill in the discover
function, which returns the list of discovered devices
.custom.discovery.enabled=true
. Specify the container for that DaemonSet as the Discovery Handler that you built above by setting custom.discovery.image.repository=$DH_IMAGE
and custom.discovery.image.repository=$TAGS
. To automatically deploy a custom Configuration, set custom.configuration.enabled=true
. Customize the Configuration's discovery_details
string to contain any filtering information: custom.configuration.discoveryDetails=<filtering info>
.custom.configuration.discoveryHandlerName
) and a name for the Discovery Handler and Configuration (custom.discovery.name
and custom.configuration.name
). All these settings come together as the following Akri installation command:Note: Be sure to consult the user guide to see whether your Kubernetes distribution needs any additional configuration.
discoveryDetails
cannot be easily set using Helm, generate a Configuration file and modify it as needed. configuration.enabled`.)Note: See the cluster setup steps for information on how to set the crictl configuration variableAKRI_HELM_CRICTL_CONFIGURATION
brokerProperties
. They will be set as environment variables in Pods that request the Instance's/device's resource.Device.properties
(Instance's brokerProperties
) were set as environment variables./akri/docs/<name>-configuration.md
on how to create a Configuration that uses your Discovery Handler.