Hi,
At the moment when we create a fleet, the default device we choose selects the arch of the fleet. That means if I select a Rpi-4-64 as the default device, I cannot add a Rpi-zero later because the releases for the fleet are 64 bits
I strongly suspect this is not an easy thing, but it would be nice to be able to select multiple arch for a fleet. the current workflow should still work (the default device select the corresponding arch) but later I’d like to select more arch. This means that, either releases shoud be tagged with the corresponding arch, or, releases shoud contain images for each of the supported archs. obviously, when I add a new arch to a fleet, I would have to build a new release before the device is able to fetch the release
Is this something you’d be interested in supporting ?
In my case I think there’s 2 alternatives:
- I can recreate the fleet with the RPI-zero as the default image. I think it should also work on a RPI4. but I don’t know if there’s devices with other arch that would be excluded this way
- I can create 2 fleets, but the maintenance become much harder once the project gets bigger (default service variables at 2 places, fleet configuration duplicated, need to switch fleets to get an overview, etc.). And I guess it would not work well with public fleets
thank you
1 Like
Hey @mathroc thanks for the question! This is something we’ve been thinking about internally for a while and are definitely planning to go ahead with. You’ve hit the nail on the head with the considerations around releases, there are a lot of caveats and a lot of things to consider UX-wise with it. Not to say this is how it will be implemented since things can change, but we were thinking that within the settings of a fleet you’d be able to toggle additional architectures, that would then allow new releases to be built that contain the images for multiple architectures as you suggest. A release would not be marked successful until it contained images for all of the architectures specified by the fleet. Of course, as you point out, when you add an architecture to a fleet then you’d have to create a new release in order for it to be supported.
At the moment though the two options you’re considering are the way to go - depending on the devices you want to use, choosing something like a Pi Zero for your fleet device type will give you a lot of options. This is what I normally do when I want to run an application across a mix of different Arm based devices. With regard to the two fleets, you’ll note this is what some of the fleet owners on balenaHub do in order to get around this problem, and we also did the same when we launched the Fold for Covid open fleet.
I’ve added your request to our tracker alongside @maggie0002 who was also asking for this same feature.