Open Assembly @ Summit

Community
1

Dear reuniting IOTlers,

the general open assembly will start in a few minutes. Please find the pad at https://hackmd.io/_nl1v0nxR6m2V0sHXm8f4g.

Cheers Oleg

2

Link yields a 403 Forbidden. Here is one that should work: HackMD - Collaborative Markdown Knowledge Base

3

Notes for persistence:

General Assembly RIOT Summit 2022

Location: Hambourg, Date: 06.09.2022. Moderation: Oliver Hahm

Agenda

  • Reduce steps to get stuff done
  • API stability
  • Debriefing from 2022.07 release
  • Mgmt Next release: 2022.10
  • Mgmt Release 2023.01
  • Moderation VMA 2022.11

Reduce steps to get stuff done

  • Moving around IP addresses makes it hard to get started.

  • Cloud integrations?

  • MCR: cloud providers such as AWS have an onboarding mechanism and a secure identify for devices. That https://forum.riot-os.org/review/22 (What URL is this?)'s a very important aspect, to have this even with the simplest devices.
    That’s why I want to have the PSA discussion later.
    We could become the OS to be able to allow this with AWS or Azure or anything really, with example code. THat would be a real killer feature!

  • HT (via chat): How well does LwM2M integration work?

  • Leandro: There’s LWM2M basic support, now even with DTLS, but people would need to write their own objects.

  • Emmanuel: (and there is an example with Wakaama)

  • Oleg: From ZĂĽhlke, could need tutorial documentation on how to connect RIOT to the various clouds. But the issues we had on that particular project were more on the hardware and app logic side. Using a modem with Hayes commands was hard to integrate in GNRC. So we used the complete TCP/IP stack of those. In FreeRTOS they could do that easily.

  • Benpicco: at ML!PA we had the same issue. These modems often don’t have raw IP, just offer access at TCP layer and above.

  • Kaspar: Propose solutions taskforce-style. Koen: Like github projects, tackling them one-by-one. Kaspar: Shouldn’t be too hard, just take a few modems and integrate them.

  • JosĂ©: we assume we have one network stack, but it’s not that simple

  • Matthias: For task force, it’d be helpful to have someone involved with real requirements.

  • Maribu: If we have a targetable socket API (multiple backends), we end up with callbacks and extra cost. We need to decide whether we accept that overhead or not.

  • Kaspar: what is the problem exactly? We need to have dual network stack support, e.g. modem-based and gnrc-based for instance?

  • Ben: When you have the modem, you also communicate with other devices that don’t have the modem.

  • HT: What’s the problem with the modem? X: It just offers the higher-layer protocols.

  • chrysn: We do accept some overhead in terms of thread switches in the network stack, so I guess we’ll be OK with something we can still optimize later at the socket layer as well.

  • Oleg: conclusion from ZUhlke talk yesterday was unclear: what was the main blockers to give RIOT another try at this point?

  • Simon: one blocker is that quick Google searches do not give obvious results such as how to use MQTT + TLS to hook up your device

(I don’t think that this was the message of the talk.)

  • Oleg: So, it’s a matter of documentation and trust – are features there and working?

  • HT: No? he was saying that the features aren’t there for production quality use. That was my understanding.

  • Ben: Plus some features are not there yet; like MQTT TLS etc

  • Simon: …

  • HT: Correct me if I am wrong but I heard him say that they wanted secure boot and firmware updates (with encryption). RIOT did not offer those features. The lack of firmware encryption also prevented them from using Microsoft Azure.

  • chrysn: About clouds, trust in code to be functional will be hard: Typical RIOT devs don’t use these (but so far use a lot of local solutions), so they will be paths not well trod.

  • Kaspar: About clouds, we want to put our devices on the Internet too, but not direclty I think. Some of our replacement (what we use) would be good to have as part of RIOT.

  • MCR: Would be lovely to have, but we need to describe the technologies, and should have an instance or two of them around. Have CI for these around, otherwise we become MQTT tutorial house. AWS MQTT tutorial … I’ve been through that, it’s atrociously bad. It’s designed for people with 1-year MCSE diploma. There’s vacuum of people trying to do this, and […?]. We probably don’t want to be there, but have to be visible there.

  • Koen: Focus issue. Kaspar focused on device. Everything outside there sounded out of scope. So we should extend the scope also to the issues you have when deploying a larger network?

  • Kaspar: We’re using SUIT due to the promise of tools coming to a standard. Our process is hacky because it’s a few Python scripts. AWS have all components under their control and just make it work together. If we want to support cloud use cases, we’re running behind their coordinated solutions. If we could put out that is our side of things, that’s working and production ready, that’d be worth a lot.

  • MCR: Would an Amazon EC2/VM you can rent that has everything on it solve that? Kaspar: Yes. It’s not that much that’s needed there.

  • [HT]: IMHO we need to get the SUIT manifest spec finished as quickly as possible.

  • Emmanuel : +1 and let’s get back to actual use cases that we can extract from eg Zuhlke woes described in their talk yesterday + document that. We’d be miles ahead. Else we could get in lost in trying to go for the “perfect solution” or for the “too many features blackhole”.

  • Simon: … Decision which stack to use is often driven from back-end side, and not from the device side.

  • Oleg: Would you contribute requirements to the task force?

  • Simon: Will answer questions, and invest time as I have it.

  • Oleg: also know someone at Zuhlke that would be willing to help in this direction

  • JJ: Some RIOT folks should make small company. It is a small investment, you already have the HW and software knowledge. Maybe need some designers from the uni campus and make a team. Worst case scenario form the PoC is that you don’t sell up-front too much.

  • Ben: There is a lot of projects in the industry looking to get sensor readings out of their installations, and they don’t know how to do it. Lot of opportunity there.

  • Oleg: Proposal for task force makes sense. Who’s interested? Kaspar, Ben, Koen, Christian, JĂĽrgen (for SSV), Simon proxy toward ZĂĽhlke, myself.

  • Do we want to narrwo the scope? How wide should it be? Thinking of getting things done faster…

  • Emmanuel: task force would be on cloud integration? […]

  • Kaspar: more general?

  • Koen: Good thing to discuss in first meeting, well-define use case and scope.

  • Emmanuel: Something too generic for a TF is also dangerous in terms of completion time.

API stability

  • Oleg: Gilles, you’re maintaining a fork of RIOT, right?

  • Gilles: It’s annexed to our application. It’s local patches but points to RIOT.

  • Oleg: How hard is it for you to update RIOT? Are you working with releases? On main?

  • Gilles: Working on releases.

  • Oleg: Are you happy with the API stability?

  • Gilles: It’s really stable. When we moved from xtimer to ztimer, things were done well; compat module gave us time to move. Wondering now on KConfig, should we move already? But it’s because I haven’t checked that. But generally, stability is really good.

  • Oleg: It’s an interesting point for me. Wasn’t following closely, and everything I worked with it again, what’s the current recommended API for timers / build system / etc? It’s obvious for you when you’re closely following.

  • Simon: Same issue. What might help is concept of deprecation; warnings on them. AFAIK we don’t have such a concept.

  • JosĂ©: We have module documentation, but we miss architectural PoV. We should write things down. Doxygen doesn’t suffice.

  • Ben: maybe more structure will help indeed. You add up and and up, and you lose track of what’s the recommended way. We should deprecate more.

  • JĂĽrgen:

  • chrysn: We do have deprecation, and removal. We just all need to take the courage and PR a deprecation!

  • Leandro: There is a warning if a module is in the deprecated list. At least for modules.

  • JosĂ©: if API changes, you don’t get the warnings?

  • chrysn: That’s not so easy to automate in C :-(

  • Oleg: Getting rid of unused features would help. But which are used / useful?

  • chrysn: Let’s just deprecate candidates, and if someone complains they can be undeprecated.

  • Emmanuel: deleting lines used to be a beloved sport in RIOT, in the past. Let’s revive this?

  • Kaspar: “Let’s have staging, not to get features in but to get stuff out”

  • Martine: “So just an empty folder?”

  • Kaspar: “Yes”

  • Oleg: is it really useful to delete features? In Linux etc. you don’t get too distracted by the plethora of unuseful features + how-to guides?

  • JosĂ©: Modules became old and unmaintained, and old maintainer isn’t around any more. We still claim support, but modules stopped working years ago. Declaring them as unmaintained would be OK.

  • Oleg: Should be tackled by tests and CI. Talking about tests passing but real feature not being usable?

  • JosĂ©: Test coverage is still low.

  • Ben: For …, OpenDSME is a good replacement. Don’t know if anyone tried the old thing in years.

  • chrysn: Code we can’t update should be deleted immediately.

  • Oleg: Agree. Unmaintained, untested code is a sign of a non-super-mandatory feature. But also we have features that are tested, but just small.

  • Ben: Packages tend to deprecate because they tend to grow outdated. Check with a Python script?

(sad laughter at “things are sitting there and getting older” … “as are we”)

  • Simon: …

  • Oleg: This goes back to the trust issue. If we have package, and claim support, and the package is outdated, it’s not helpful for trustworthiness.

  • Simon: with 3rd party packages, it’s also a version issue. It’s fine if we have latest and greatest, but if you have any version, that’s better than an update.

  • Kaspar: To compare with Rust, if any of your dependencies has an update, GitHub will give you an automated PR and run CI to see if things are still good.

  • Emmanuel: Bar might be lower than we think, we just need something working with some version of e.g. a pkg that is not ultra old. Then we pass this first hurdle that Zuhlke was reporting we failed to pass.

  • Karl: modules, you pin them to specific versions, but upstream they develop, and then we get into security/feature gaps

Debriefing from 2022.07 release

  • chrysn: (about audio issues) Yeah, OK it’s me :-(

So, very brief summary in text: Things went fine, but there are a lots of places around the RM documentation that I’ll yet want to update. For example, I only found the wiki entry listing RM tasks way later than I should have because it’s not linked from the core documentation – and then, even that does not always agree with what is done in practice. (For example, it makes a lot of sense to selecively rerun tests on RCs if there were only small changes, but that’s only how it’s done, not how it’s documented).

Next release: 2022.10

Leandro will manage this one.

After that: Release 2023.01

Kaspar will manage the anniversary release.

VMA 2022.11

Marian will moderate.

1 Like