Support CoRE resource discovery protocol

[jiayihu]

Is your feature request related to a problem? Please describe.
no

Is your feature request related to a way you would like Akri extended? Please describe.
I've read the Roadmap and it stated to open a feature request for unsupported protocols, so here it is. I'd like to request support for the CoRE resource discovery, as described in RFC6690. It's used by my devices which implement CoAP communication.

Btw I think I'm going ahead and try to implement it myself, I hope I can ask for help on the Slack channel in case.

[kate-goldenring]

Hi @jiayihu. I am not familiar with CoAP, but it sounds like a great addition for constrained environments. Is there a scenario you have in mind?

If you are starting the implementation journey, we have an extensibility document that walks through how to add a protocol. As a note, we are currently working on improving the process of extending Akri, looking into implementing one or more of these extensibility ideas. The current process for extending Akri, as you may notice, has a fair bit of steps, but feel free to ping Slack with any questions.

If you are interested in contributing it to Akri, you could create a proposal to walk through the use case and implementation. For example, @DazWilkin created one for Zeroconf. We are looking at moving our proposals to HackMD for easier discussion, so you could start one there if interested.

[jiayihu]

Hi @kate-goldenring, thanks for the quick reply! I have implemented the CoAP protocol in my embedded Rust devices because it allows to communicate RESTfully while avoiding the inefficiency of TCP and HTTP in constrained environments. It's based on UDP. For instance my device could return temperature measurements as resources when the broker pings GET /well-known/core by implementing the CoRE protocol.

I was already reading the extensibility document, so I'll let you know if I run into any issue. And of course I'll gladly contribute back to Akri once I have anything worth it.

Btw is there any way to run the end-to-end/Rasp demo without v4l2 loopback? I have a Rasp cluster running Alpine Linux and I would prefer avoiding to compile the kernel. That's a challenge I don't think I'm ready for 😄 Otherwise I guess I'll just have to get started right with the custom CoRE broker.

[kate-goldenring]

Cool! I'm excited to try it out :) That temperature use case could integrate well with our anomaly detection web app, which displays any anomaly temperature values in red.

For the e2e demo, instead of using the debian package, on the second step of setting up the mock video devices, you can clone the repo, build the module, and setup the module dependencies like so:

git clone https://github.com/umlaeute/v4l2loopback.git
sudo make installs
sudo make install-utils
sudo depmod -a

Then, you should be able to continue on to step 3 (modprobe).

Or, if you are just using the end-to-end demo just to try out Akri, you could get a feel for how it works by using our debug echo Configuration. We use it for testing Akri. For discovery for Debug Echo, all the Agent is doing is checking a text file (/tmp/debug-echo-availability.txt) to see if the word OFFLINE is there. So long as "OFFLINE" is not written to that file, it automatically discovers two "foo devices" on each Node and the controller will deploy brokers (that consist of just empty nginx containers) to each "foo device". Then, you can make the devices "go offline" by writing "OFFLINE" to the Agent's /tmp/debug-echo-availability.txt file. The flow would look like this:

1. Install Kubernetes
2. Install Akri with the Debug Echo Configuration. For DebugEcho, it must be enabled in the Agent. Also, make the "foo" devices "local devices" rather than shared devices that all Nodes can see by setting debugEcho.shared to false.

    helm repo add akri-helm-charts https://deislabs.github.io/akri/
    helm install akri akri-helm-charts/akri \
    --set agent.allowDebugEcho=true \
        --set debugEcho.enabled=true \
        --set debugEcho.shared=false

3. Observe the Akri components like in the end-to-end demo

   watch kubectl get pods,akrii,akric,services

4. "unplug" the foo devices from a Node by writing "OFFLINE" into the Agent's /tmp/debug-echo-availability.txt file. Replace <agent hash> with the appropriate hash of one of your Agents.

   kubectl exec --stdin --tty akri-agent-daemonset-<agent hash> -- sh -c "echo 'OFFLINE' > /tmp/debug-echo-availability.txt"

5. Watch two instances and two pods come down.

   watch kubectl get pods,akrii,akric,services

This may help demo Akri without having to finagle with the v4l2loopback module.

[jiayihu]

The echo demo sounds wonderful, but also building v4l2loopback may be fine although I always have nightmare when compiling C projects. I think I'll definitely go with the easy path with Echo Configuration. It would be nice if you could add it the docs in future.

Thanks for help, I think you're doing a great job with this project!

[jiayihu]

Ah interesting question emerged while I was writing the Proposal doc in #203

I think the current implementation would need a controller to accept queries about available resources and return the broker which can communicate to the device. The device is listed as generic akri.sh/coap-core-021dd7 resource on the node, which is pretty much useless. A better label would be akri.sh/oic.r.temperature-021dd7, that is the discovered resource. This would allow using the K8s controller for scheduling pods which need the resource

Is my intuition right or did I miss something?

[github-actions]

Issue has been automatically marked as stale due to inactivity for 45 days. Update the issue to remove label, otherwise it will be automatically closed.

[github-actions]

Issue has been automatically marked as stale due to inactivity for 90 days. Update the issue to remove label, otherwise it will be automatically closed.