Balena Fleet Questions (GitHub, privacy and preloading)

[chrisys]

Hey @maggie0002 thanks for all of the questions and thanks for trying the open fleets functionality on balenaHub!

I’ll try to answer everything here individually but feel free to come back to me if you have any more questions. The open fleet functionality, along with the rest of hub, is in active development so now is a great time to let us know your needs and influence the road map.

I see for Balena Blocks that GitHub submodules are not supported? I assume that is the case for Balena Fleet too?

The important thing we’re trying to promote is that blocks are reusable containers or chunks of functionality, how they’re implemented is pretty much up to the developer. Blocks are thought of as not doing anything useful standalone and so someone is always going to have to integrate them with other functionality. In regards to that then it shouldn’t matter if submodules are used or not as they’re a separate aspect of source control that’s unrelated. We also have a blog post introducing blocks that has a bit more info. As for fleets, the same applies here; it doesn’t matter if submodules are used in GitHub because the full application source is pushed when you create a release.

A lot of the fleets say: ‘Allow a few minutes for your device to download the application.’. Are the images not preloaded?

The images are not currently preloaded, but dynamic preloading is a problem that we’re working on solving. It’s a hard problem to solve, as the preloading process takes time and so isn’t feasible to do on-demand, and simultaneously we don’t want to preload and store images for every supported device type for every release. There may be a concept of serving a file that contains both the OS image and the containers and then we apply them after download, e.g. within Etcher, or on the device itself.

Assuming the pre-loading isn’t available, can we still create open fleets but preload an image with my app that is connected to the open fleet, and then distribute that image file myself?

Absolutely!

If it isn’t preloading, what is the connection to the GitHub repo for? Merely to fetch the Balena.yml?

It is used in the ‘fork this fleet’ process to enable a user to deploy a copy of the code for themselves. Additionally, open fleets are only available for non-commercial, open-source projects, so this link should establish a link between the fleet and the open-source code that’s running on that fleet. We’re working on methods to synchronise a fleet with a GitHub repo, so that whenever a merge is made to the main branch, a release can automatically be created and update the fleet (if desired).

Can you provide a GitHub URL that points to a specific branch, or will it always use whichever default branch is set on the repo?

For the most part we’re just looking for a link to the repo, but it is possible to specify a direct path to a tarball using balena.yml that will come into play when a user uses the ‘fork this fleet’ or ‘deploy with balena’ functionality - read more.

I see there is an interactive map available of active devices. Can that be disabled? It is in my users interest to not have the countries, nor any more specific areas the devices are operating in public knowledge. Privacy is such a hot topic.

Currently it cannot be disabled, but I’ll record this request and put it on the roadmap as a configurable option to implement. It’s worth mentioning though that the location data is based on IP geolocation so isn’t super accurate, and then as a secondary measure, the reported latitude and longitude is limited in accuracy to 10 miles.

I am offering multiple architectures (armv6hf, armv7hf etc.) to users for the same app. In Balena this means I have to create a different application for each and deploy to each individually due to the build processes having to run for each.

You’re 100% correct in raising this as an issue; we’re working on enabling multi-architecture fleets to solve this very use case. The current thinking is that you’ll be able to enable builds for additional architectures within a single fleet, so any of your application’s supported device types will be able to join and download a release built for their architecture. As for today though, you’ve worked around it the only way we know how. You’ll see we did the same thing for the Rosetta app.

thought adding the GitHub URL would read from the balena.yml file. Turns out you need to push the app first before it will read it.

Yup you got it, the idea is that the balena.yml file is versioned along with the release that’s running on the fleet. If you’ve (for example) supported an additional device type with a new version of the code, you’d push that version and the new device type would appear. If there’s an issue which means you need to roll back and pin the fleet to an older version, then that device type would disappear again, as of course the older version doesn’t support it.

Thanks again for all of the feedback! Myself and some colleagues were really happy to see someone making use of this new functionality in the way that it’s intended, and we’d love for you to keep in touch and continue to let us know how we’re doing or if there’s anything else you need.