Hey @Maggie 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.
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.
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.
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).
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.
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.
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.
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.