Does anyone know if there is a way to access a device’s supervisor API key (BALENA_SUPERVISOR_API_KEY) from the host OS? I understand you can set the io.balena.features.supervisor-api label to access it from within an app container, but I need it on the host to support a custom plymouth boot screen that displays a real time status.
Hi David,
There’s probably a way to get the API key from the host OS, but it would definitely be easier inside an application container. Have you tried running Plymouth inside a container?
Hello @drcnyc
Did you succeed trying to run Plymouth inside a container? Let us know more insights about this.
@jakogut @mpous thank you for the suggestions. Running plymouth inside a container would not meet our requirements as we need to display status messages to the user as the device boots up, which starts well before balena supervisor and any other containers are actually loaded. The last step in our plymouth boot screen is to display the status of the app containers (i.e. are they downloading / running / etc.), which is the step that requires the supervisor API. I ended up simply accessing the supervisor via the openbalena supervisor relay service, since I have the API key for openbalena on the host OS. This results in a delay vs. real time (i.e. it takes a few extra seconds for the supervisor to report to openbalena, and then for us to get the data from openbalena), but still generally met our needs. It’s too bad that I have to go to a remote server to get the status of the device I am on locally, but I don’t see a way to access the supervisor from the host OS in any other way.
Hi @drcnyc, thank you for the extra context. It’s good to hear that you have a workaround for now. Then for sure let us help with improving the setup.
First of all, I don’t think we expose the supervisor API key in the HostOS. I’ll raise this as a question and potential feature request to my teammates maintaining the supervisor.
Next, in general we believe that containerization is the way to manage IoT devices. So we’d like to encourage and help you to run that plymouth service inside a container. We appreciate hearing your feedback on how to achieve that. Once the supervisor is up and running, you will have access to all these stats. You could construct your application so that plymouth service starts the first and reads the status of other containers. Do I get it right that you need faster supervisor start time at device boot? Is that the main blocker here? If so, I appreciate quantifying the need. How quick do you need it to be?
Do you know that you could preload your images to the device?
Here is our masterclass explaining how to achieve step by step:
So you could preload that plymouth container which will speed up things. Furthermore, in such a way, you could consider exporting the key to a volume where HostOS can access. So this eliminates the need to go through remote server to fetch the key.
Let us know if these help or not.
Hi @drcnyc, have you made any progress here? Can we help with anything further?
Let us know if what I typed earlier helped or not. Appreciate the feedback.
@gelbal thank you for checking in. As I mentioned above, we were able to solve this problem b accessing the supervisor via the openbalena supervisor relay service, since I am able to access the API key for openbalena on the host OS (via /mnt/boot/config.json). This results in a bit of a delay because it takes a few extra seconds for the supervisor to report to openbalena, and then for us to get the data from openbalena - but it still generally met our needs. There is no way to run plymouth in a container as you guys had suggested, because it’s a startup boot process, which is intended to run well before the supervisor container starts. Just FYI, we are running openbalena and our own balenaOS build, which is how we are able to do this - I don’t think this would be possible for someone using stock balena OS.