Re: [kanto-dev] Software update

[Dirk Van Haerenborgh <dirk.vanhaerenborgh@xxxxxxxx>]

Hi Tina,

Regarding communicating with the local broker. I can only connect to it from within the container if I set mosquitto to listen on all interfaces and allow anonymous clients.
That's not something I'm comfortable with for an edge device.
Since mosquitto is installed as a dependency of kanto, is there some config I'm missing? The suite connector mosquitto config only contains some logging directives.

Kind regards,
-Dirk

Dirk Van Haerenborgh Software engineer

Aloxy The Beacon, Sint-Pietersvliet 7 2000 Antwerp www.aloxy.io

---

From: kanto-dev <kanto-dev-bounces@xxxxxxxxxxx> on behalf of Gramatova Dr. Konstantina (IOB/PAD-PM1) <Konstantina.Gramatova@xxxxxxxx>
Sent: Thursday, 16 June 2022 17:39
To: kanto developer discussions <kanto-dev@xxxxxxxxxxx>
Subject: Re: [kanto-dev] Software update

 

Hi Dirk,

great news that you have the desired setup running!

Should you have any further questions/bumps along the MVP way - don't hesitate to contact us 🙂

Regarding hawkBit and the self/OS/firmware updates:

When you get to this point in time - we provide a fairly flexible software update component that implements the SoftareUpdatable v2 model and can run customizable scripts that can execute whatever logic you desire inside - OS/firmware or other kind of update/logic. It is enhanced with a persistence mechanism to ensure the update process is reboot-durable. An example use case is our integration with RAUC we realized with exactly this component triggering the update and reporting the status back.

What we will also provide soon is a SoftwareUpdatable client library that will enable you to implement your own on-device logic of this feature if needed. And given in mind Kanto can run on a gateway device - it can also enable updates distribution to its connected end devices as well.

We have had such software update external-API-to-SoftawareUpdatable transformation use cases before and we can help you with a recommendation/support/collaboration on getting it running for your use case as well 🙂 Just give us a hint when you get to this point and start digging deeper into this scenario.

Looking forward to your updates on the MVP!

Tina

Mit freundlichen Grüßen / Best regards

Dr. Konstantina Gramatova

Bosch IoT Gateway Software 3 (IOC/PAP-GW3)
Bosch.IO GmbH | Ziegelei 7 | 88090 Immenstaad | GERMANY | www.bosch.io
Tel. +359 2 9055876 | Fax +359 2 95326-17 | Threema / Threema Work: SKDTDZCH | Konstantina.Gramatova@xxxxxxxx

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

---

From: kanto-dev <kanto-dev-bounces@xxxxxxxxxxx> on behalf of Dirk Van Haerenborgh <dirk.vanhaerenborgh@xxxxxxxx>
Sent: Thursday, June 16, 2022 5:26 PM
To: kanto developer discussions <kanto-dev@xxxxxxxxxxx>
Subject: Re: [kanto-dev] Software update

 

Hi Tina,

Thanks a lot for that hint. That was just what I needed.

We now have a node-red container managed by Kanto that allows us to create custom pipelines starting from the local mqtt broker. Pretty cool stuff!

What's left for this experimentation phase is how we can update Kanto (or even the host system?) itself. We've never used hawkbit before so even if the concepts are transportable, we're somewhat in the dark, still 🙂

That being said, our main focus now will be to move to a MVP. Once that is finished, we'll be looking at the update feature itself.

Kind regards,
-Dirk

Dirk Van Haerenborgh Software engineer

Aloxy The Beacon, Sint-Pietersvliet 7 2000 Antwerp www.aloxy.io

---

From: kanto-dev <kanto-dev-bounces@xxxxxxxxxxx> on behalf of Gramatova Dr. Konstantina (IOB/PAD-PM1) <Konstantina.Gramatova@xxxxxxxx>
Sent: Wednesday, 15 June 2022 18:30
To: kanto developer discussions <kanto-dev@xxxxxxxxxxx>
Subject: Re: [kanto-dev] Software update

 

Hey Dirk,

I'm really happy to see that you have managed to grasp our key concepts and you are already experimenting with them in interesting use cases!

So to jump in and confirm:

Since Kanto is running its own local broker, we though it'd be pretty nice if we could piggy-back on it. As such, the container does not need to setup a connection to Hono itself.How is this envisioned for Kanto?

It's envisioned exactly this way : ) . The local broker is intended to be shared and used for all the local communication running on the device (not only Kanto-specific but apps-specific as well). Whereas the suite-connector component takes care of the hard work around the remote one - serving it (connect/reconnect/sync etc.) and publishing all the remotely sent data to the local broker and vice versa. This ensures for the locally running components to require only a local connection to the broker utilizing it for their communication - both remote and local - the suite-connector takes care of the rest. So shortly - no, the container does not need to setup a connection to Hono itself - it's expected for it to communicate to the local broker only.

Extending from this: it'd be extra cool if our container could receive commands itself from the local broker (coming from the cloud as well).

Given in mind that the suite-connector is running "on top" of the local broker and takes care of proxying all messages (local & remote) back and forth - yes, your container can receive the remote commands from the local broker. Once a remote Hono command is received, it is published to the local broker on the respective Hono MQTT topic so that the local apps can handle it if subscribed.

This is actually one of the key concepts on how the edge functionality is expected to be extended using Eclipse Kanto - utilizing the local communication that is handled via the digital twin (Ditto) and semantics (Vorto) model and managed via Hono commands/events/telemetry patterns. In other words - plug in to the local communication with new Ditto features to handle it : )

This is also something I would encourage you to do if you are thinking about modelling extensions you would like to have enabled using Kanto so that they can benefit from all this communication management and modelling leading to a single remote connection handled transparently for the local apps.

And one side hint if you decide to try this setup out - for the containers that would like to use the local broker, there is a "magic" reserved keyword host_ip that is automatically resolved to the IP of the host machine (and broker running there) on the default bridge network interface (kanto-cm0) so that the containerized apps can use it to connect to the broker via mapping an extra host to it via e.g. the CLI option --hosts broker_host_name_in_app:host_ip

This broker_host_name_in_app can then be used statically in the apps code to ensure flexibility and no hard-coded IPs.

Please keep in touch with us on your exploration journey - we are happy to support and explore with you!

Tina

Mit freundlichen Grüßen / Best regards

Dr. Konstantina Gramatova

Bosch IoT Gateway Software 3 (IOC/PAP-GW3)
Bosch.IO GmbH | Ziegelei 7 | 88090 Immenstaad | GERMANY | www.bosch.io
Tel. +359 2 9055876 | Fax +359 2 95326-17 | Threema / Threema Work: SKDTDZCH | Konstantina.Gramatova@xxxxxxxx

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

---

From: kanto-dev <kanto-dev-bounces@xxxxxxxxxxx> on behalf of Dirk Van Haerenborgh <dirk.vanhaerenborgh@xxxxxxxx>
Sent: Wednesday, June 15, 2022 2:55 PM
To: kanto developer discussions <kanto-dev@xxxxxxxxxxx>
Subject: Re: [kanto-dev] Software update

 

Hi Tina,

Thanks for the reply. We had figured out most of this by reading through the Kanto source code.

Since we now have a better picture of container management itself, we're experimenting with the next steps.

Say we have a container that receives messages from devices in the field (through a device mapped to the container).
Since Kanto is running its own local broker, we though it'd be pretty nice if we could piggy-back on it. As such, the container does not need to setup a connection to Hono itself.

How is this envisioned for Kanto?

Extending from this: it'd be extra cool if our container could receive commands itself from the local broker (coming from the cloud as well).

Or should we look at Kanto only as a container/edge device manager where our containers should not know of its existence at all?

Kind regards,
-Dirk

Dirk Van Haerenborgh Software engineer

Aloxy The Beacon, Sint-Pietersvliet 7 2000 Antwerp www.aloxy.io

---

From: kanto-dev <kanto-dev-bounces@xxxxxxxxxxx> on behalf of Gramatova Dr. Konstantina (IOB/PAD-PM1) <Konstantina.Gramatova@xxxxxxxx>
Sent: Tuesday, 14 June 2022 17:00
To: kanto developer discussions <kanto-dev@xxxxxxxxxxx>
Subject: Re: [kanto-dev] Software update

 

Hey Dirk!

We are eagerly preparing it as well : ))
I apologize it took a while to get back to you but I'll try to give some guidance while the docs are being prepared:

The payloads Kanto uses are a combination of Eclipse Ditto and Eclipse Vorto and how these two are combined you can read about here. For the actual MQTT communication - the Eclipse Hono MQTT definitions are used (see here).

Having that said,  for container management we have a Ditto feature registered per running container using the following Vorto model - Container v1.4.0.

To update a running container, you will have to:

• use the update operation from the model
  
• map it to the proper Ditto Live messages format to initiate a command
  
• send it to the device via the commands Hono topic.
  

A ready-to-fill Ditto payload template is also available for you to check out in our getting started Python script (hono_commands.py) - you can use it as a base and substitute the templated pieces in it according to the guide so far.

Such an example could be (using the device info from the getting started guide):

{
  "topic": "demo/device:edge:containers/things/live/messages/update",
  "headers": {
    "content-type": "application/json",
    "correlation-id": "correlation-id-of-choice",
    "response-required": true
  },
  "path": "/features/Container:bb796f5c-c292-4289-b1bc-a3236cc88722/inbox/messages/update",
  "value": {
    "resources": {
      "memory": "3M"
    }
  }
}

​Publishing this payload on the proper commands Hono topic will update the resources used by a running container with an ID 
bb796f5c-c292-4289-b1bc-a3236cc88722
on the edge device.

I hope this enlightens the picture a little bit further - ping back if more help is needed!

Have a great day!

Tina

Mit freundlichen Grüßen / Best regards

Dr. Konstantina Gramatova

Bosch IoT Gateway Software 3 (IOC/PAP-GW3)
Bosch.IO GmbH | Ziegelei 7 | 88090 Immenstaad | GERMANY | www.bosch.io
Tel. +359 2 9055876 | Fax +359 2 95326-17 | Threema / Threema Work: SKDTDZCH | Konstantina.Gramatova@xxxxxxxx

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

---

From: kanto-dev <kanto-dev-bounces@xxxxxxxxxxx> on behalf of Dirk Van Haerenborgh <dirk.vanhaerenborgh@xxxxxxxx>
Sent: Thursday, June 9, 2022 3:16 PM
To: kanto developer discussions <kanto-dev@xxxxxxxxxxx>
Subject: Re: [kanto-dev] Software update

 

Hi Tina,

We're then eagerly awaiting the docs 🙂. Since we're still pretty much experimenting with this, even incomplete docs would be an immense help.

We haven't gotten much more to work than the getting started docs.

Would you be able to shed some light on the payload needed to update a running container?

Kind regards,
-Dirk

Dirk Van Haerenborgh Software engineer

Aloxy The Beacon, Sint-Pietersvliet 7 2000 Antwerp www.aloxy.io

---

From: kanto-dev <kanto-dev-bounces@xxxxxxxxxxx> on behalf of Gramatova Dr. Konstantina (IOB/PAD-PM1) <Konstantina.Gramatova@xxxxxxxx>
Sent: Wednesday, 8 June 2022 19:08
To: kanto-dev@xxxxxxxxxxx <kanto-dev@xxxxxxxxxxx>
Subject: Re: [kanto-dev] Software update

 

Hi Dirk!

Really glad to see that Kanto is an interesting project for you and your team!

Regarding the docs - we are in the process of making them available so soon we'll be able to refer you to a more in-detail description on how the concept works.

Your observation is correct - we are using a client-side implementation to handle the hawkBit logic - in specific via the SoftwareUpdatable v2 model and flows it implies.

The communication, however, is achieved via a combination of Ditto & Hono and the model specifies the semantics of the payloads being transferred on top of it. Currently, we support only an MQTT endpoint for such a remote communication, but the CDN where the managed artifacts referred per installation/update could be downloaded from may be reachable via HTTP/HTTPS.

I hope this info is helpful!

Please, drop a message back if further clarifications could be helpful as well!

Have a great day!

Tina

Mit freundlichen Grüßen / Best regards

Dr. Konstantina Gramatova

Bosch IoT Gateway Software 3 (IOC/PAP-GW3)
Bosch.IO GmbH | Ziegelei 7 | 88090 Immenstaad | GERMANY | www.bosch.io
Tel. +359 2 9055876 | Fax +359 2 95326-17 | Threema / Threema Work: SKDTDZCH | Konstantina.Gramatova@xxxxxxxx

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors: Dr. Stefan Ferber, Dr. Aleksandar Mitrovic, Yvonne Reckling

---

From: kanto-dev <kanto-dev-bounces@xxxxxxxxxxx> on behalf of Dirk Van Haerenborgh <dirk.vanhaerenborgh@xxxxxxxx>
Sent: Tuesday, June 7, 2022 2:46 PM
To: kanto-dev@xxxxxxxxxxx <kanto-dev@xxxxxxxxxxx>
Subject: [kanto-dev] Software update

 

Hi all,

We're currently experimenting with Kanto and we read that it also supports self-updating.
Is there any documentation for that? I've read the source and I've seen that the update process itself uses the hawkbit client libraries. Do we need to have an instance of hawkbit running, or will an HTTP endpoint suffice?

Kind regards,
-Dirk Van Haerenborgh

Dirk Van Haerenborgh Software engineer

Aloxy The Beacon, Sint-Pietersvliet 7 2000 Antwerp www.aloxy.io