Dependency upgrades (API v0.209.2)

[bartversluijs]

I've updated the following dependencies:

• Updated open-balena-api to 0.209.2 (minor change / environment variable changes)
• Updated open-balena-vpn to 11.4.6 (minor change)
• Updated open-balena-registry to 2.25.3 (minor change / environment variable changes)
• Updated open-balena-s3 to 2.13.8 (patch)

---

I've tested the changes by creating a new instance of open-balena.
The following OS's have been tested with Balena CLI 13.1.13:

• BalenaOS v2.65.0+rev1, supervisor 12.2.11 (development & production image)
• BalenaOS v2.88.5+rev1, supervisor 12.11.0 (development & production image / "developmentMode": true)
• BalenaOS v2.98.33, supervisor 13.1.11 (development & production image / "developmentMode": true)

What I've tested with these BalenaOS versions:

• Provisioning with fleet
• Downloading release from fleet
• Update release from fleet
• VPN tunnel -> SSH
• Local mode

[ghost]

Your landr site preview has been successfully deployed to https://landr-bartversluijs-repo-open-balena-preview-149.netlify.app

Deployed with Landr 9.4.20

[richbayliss]

I found this too @bartversluijs so I would 👍🏻 your MR if I could 😄

It would be useful if the Supervisor could detect the 404 and actually offer a more user-friendly error message; or if possible revert to the v2 state endpoint.

[bartversluijs]

Thanks @richbayliss,

I'm still doubting if I should change the open-balena-api version to v2.0.0 (because that's the latest).
But I'm awaiting some feedback for that.

About the 404, I don't know if it should be changed. There's a new API (v3) and the latest BalenaOS uses that. For backward compatibility, supporting v2 would suffice, but isn't that a "hacky" solution?

In my opinion, only the API should support the older endpoints for backwards compatibility, but if there's a new release of BalenaOS that makes use of new endpoints, the API should be updated. Otherwise, you'd always have to support older endpoints of the API as fallback just in case the API isn't updated yet. So if the endpoint doesn't exist yet, you have two options:

• Update the API
• Use an older BalenaOS version

---

I'm really thankful for openbalena, but (and I'm shooting myself in the foot here) I believe that openbalena users should adjust to the work the Balena team is doing instead of Balena testing and supporting all sorts of scenario's (like this one). As long as the latest BalenaOS version works with the latest open-balena-api, I'm happy to invest time to test the upgrade and making a PR 🙂

[richbayliss]

I guess the issue here is that a new OS was released, and wasn't checked against the current openBalena distribution for compatibility so the docs could be updated before the distribution was ready.

I also don't know what the solution is @bartversluijs but I feel that this current situation isn't a good one :)

It would be nice if there was a way to tag the open-balena-api images so that we have not just a latest tag but also a stable tag --- the latter being an API version we can update to with some degree of confidence that it's not got breaking changes with the OS etc 🤷🏻 or something to that effect...

[dfunckt]

Looks great, thanks @bartversluijs !