Please use the thread below to discuss the related blog post:
https://balena.io/blog/the-road-to-multi-app-transitioning-balenacloud-applications-to-fleets
Chris here, hanging out down in the comments - if youâve got any comments or feedback regarding the changes to fleets let me know!
Absolutely brilliant, no-brainer, fantastic change in the Balena naming hierarchy.
The use of âApplicationsâ to refer to a fleet of devices always drove me a little batty, particularly because we group our devices by customer, so I had to explain to everyone that the Balena name for a customer fleet of devices was, âApplicationâ - which made no sense to anybody.
Renaming the fleet of devices to âFleetsâ is the height of product management brilliance. Taking something, sharpening it, and getting it closer to itâs true nature.
Thank you so much.
1 Like
@ghshephard welcome to the forums, thanks for taking the time to sign up and share your feedback - itâs a pleasure to hear this and makes all the thought we put in to this stuff totally worthwhile! Glad we could make things a little easier for you 
I completely agreed with ghshepherd. I came here purely to comment on the product management strategy moves youâre making. Very few product managers / teams are able to combine their vision with execution and clear communication to bring execs, peers, engineering teams and customers along on that journey.
Aside from the name change, the grander vision described in that blog post is spot on for what I expect out of balena as a user and would do if I were in your shoes. .
Well done, keep going.
-Recovering product guy
1 Like
@tideline3d / Josh,
First, welcome to our Forums!
Second, we appreciate the kind words and the feedback. Definitely stay tuned for what @chrisys and our crew have in store. In the meantime, I hope you continue using and enjoying balena. Take care.
Great name change, so I completely agree with @ghshephard!
Iâm wondering, as an openBalena user, what are the consequences for openBalena?
First thing that comes to mind is that I shouldnât update the Balena CLI and SDK to the new minor version, same goes for the Node.js SDK. And will this mean a new major or minor upgrade of openBalena?
Thanks in advance and keep up the great work!
1 Like
Thanks for the feedback all!
@bversluijs with regards to openBalena, we of course want to roll the changes out there too in order to make sure the experience is the same. I was chatting with one of our API engineers (and founder!) @_Page about it yesterday and he was explaining that itâs not 100% straightforward as the technology weâre planning on using to ease the transition in balenaCloud is not present in openBalena. It may mean that the openBalena transition is a bit more abrupt and could take longer to implement; for that reason I couldnât say at the moment if it will end up being a major or minor version bump. As I say though, weâll definitely be making the same name change there too eventually.
With regards to the balenaCLI, you should be fine using the new release (12.45.0) as the API resources it uses have not yet changed. It should show things as fleets but work with openBalena applications behind the scenes. The SDKs havenât been updated yet although are in progress, but the same will apply there too - the application models will remain and you can continue to use those, but the new fleet ones will not work with openBalena until that API has been updated. Our approach is always to make additive changes as much as possible and not break existing functionality, but of course at some point we need to deprecate and drop the old stuff.
I hope that helps - let me know if youâve got any more questions!
1 Like
@chrisys Deleting a fleet pops up this question
âPlease type in the number of affected labels.fleet_plural to confirm:â
Also Grant support access asks:
âAllow balena support team access to this application forâ (time)
Cheers
Nico
1 Like
@nmaas87 noted! Thank you for highlighting these!
1 Like
Does this mean that you consider allowing to move a device from one fleet to another without loosing the application and/or the configuration?
I have often found myself missing such a feature, but the current behavior is to erase all persistent data when a device is transferred.
Hey there @krix; no it doesnât mean that unfortunately, as far as functionality is concerned the behavior will be exactly as it was before. The device has to conform to what the fleet dictates, so it wouldnât make sense to bring any services and data from another fleet into a different fleet.
Could you give any more information about your use case? If you can explain what youâre trying to achieve by moving devices between fleets and having data persist we might be able to find a way to achieve it some other way.
Currently we are migrating some devices from Intel NUC image to Generic X86.
I have not found any other way to do this, than creating a new âapplicationâ (now âfleetâ), and for each device backup the device data, reinstall the device from scratch, and restore the backed up data.
This is both time consuming and not without risk. Also it creates a new device UUID, which means there are a lot of dead devices and a lot of cleaning up.
@krix you should be able to add Generic X86 devices to your Intel NUC fleet; you can have mixed device types within a single fleet as long as they share the same architecture.
You can also retain the device UUID by moving the config.json file from the old device to the new one. You can even change the device type of the device using the dashboard, but of course that wouldnât cause the OS to change. If you need help migrating the devices do open a support ticket from the dashboard and weâll help figure out the most efficient way for you to do this!
Great news! We would currently need to switch between multiple balena-applications to fulfill our requirements. E.g. when customer âXâ needs container âAâ , but not container âBâ and so on, we would need to compose multiple possible applications (app_A_and_B, app_only_A, app_only_B).
We currently circumvent these restrictions by deploying a docker-registry and we put a UI above docker-compose to run our own âapplicationsâ.
Does your multi-app approach solve exactly this problem?
s/application/fleet/g your masterclass (and other) docs
@haronaut I think what weâre planning answers your use case in that youâd be able to use the balenaCloud UI to do what youâre currently doing within your own custom UI. Youâll be able to add âappsâ, one with container A and a second with container B. After these apps have been created youâll be able to install them on a fleet of devices (even just 1 device if required). New releases of those apps would then be applied to all the fleets where they have been installed.
With this functionality it sounds like youâd need to set up each of your customers or groups of devices you wish to target within their own fleet, and then youâd be able to change what apps are installed on a per-fleet basis but still update each app once from a central location.
I think this would handle what youâre asking but please let me know if not, itâs interesting to hear what use cases there are out there for this technology so we can make sure that we build the thing that people need in the real world.