Subfleets implementation

Hi guys,

in our usecase we have groups of devices under one fleet installed in separate locations. Currently we use tags to specify the location and quickly sort devices in the device view in order to mass-deploy or change all devices at given location at once. Having a separate fleet for each location would
be a overkill and hassle for developers(settings, deployments), but would be great for the support guys.

I think it would be nice for our support guys to have the possibility for grouping devices under same fleet in balena UI e.g. some kind of subfleets.

Or maybe the correct solution will be by using apps (currently in Alpha) and have really a separate fleet per location (with script for configuration sync among them). This way developers would be pushing new version of app to one location and fleets will be updated accordingly. Right?



Hello @filemon what is the problem that you have?

You’ve already mentioned that you are using tags to visualize in the UI the devices by location (depending on the tag associated). Are you deploying new releases depending on the tag?

Our usecases are:

  1. deployment location by location in A/B manner.

  2. device returns - given customer(location) returns some device and we transfer the device to new location. Would be nice to use Move device to other fleet for this instead of changing the tags.

  3. support - quickly see the status of all devices at given location. Currently done by sorting out the devices based on tags and scrolling. Works ok in our case now (60 devices). But we expect to have hundreds of devices soon, so navigate to separate fleet would be handy.

  4. API - we have apps interacting with Balena API. Getting all devices at given location means to get all devices, check tags of all of them and proceed with operation. Would be nice and cost effective to get all devices for given location in one go.

Make sense @mpous ? Thanks for your time.

Hi @filemon,

We have been discussing internally about a use case like this, which would be solved by what we at the moment refer to as “release channels”.
We originally intended to offer device tags & device pinning, so that it would make it easier for fleet owners to do such A/B testing or gradual fleet updates.
How we have seen other customer achieving this right now is:

  • assigning tags to all devices eg update_group: A, update_group: B
  • then using “Add filter” to create a filter for each of those groups & then using the “Save as view” button in the filter summary to make easy to quickly see only each specific group
  • pinning their fleet to release X
  • and finally updating one of their groups by using the saved view for the target group, ticking the table header checkbox so that all devices of the visible group are selected, and pinning them to release Y using the respective entry from the Actions.

Given that our API offers OData endpoints, you can actually retrieve all the records with their tags in one request, or even better update all devices with a given tag to a given release without first having to retrieve them at all.
Let me point you to own of our example repositories that does exactly that:

I’ve associated this ticket with the respective internal improvement we have to track progress for “Release Channels” so that we can give you a heads up once that gets implemented and gets released.

Let us know if you face any issues.

Kind regards,

1 Like

Thanks @thgreasi for the perfect answer.

  1. views are ok for us
  2. I didn’t know you can filter devices based on tags (not returned in a standard payload). Thanks for this, working like a charm!



One note - Views config in Balena Cloud is apparently stored in session/local storage, so unfortunately you need to set them up in every browser.