Is there an easy way to figure out inside a service that the current image is prod or dev?
Hi,
Currently, the Supervisor API is able to return OS version via the GET /v1/device endpoint, but not variant (prod/dev). A Supervisor endpoint would be an easy way to access this kind of information, and as one of the Supervisor maintainers, rest assured that we are working on this. We’ll notify you when an endpoint matching your needs is available in production, then you may upgrade your Supervisor via self-serve upgrades (Self-service Supervisor Upgrades - Balena Documentation).
As for what you can do right now, to get device information not available from the Supervisor API, you can query the balena API by adding the io.balena.features.balena-api label to your service (see docker-compose.yml fields - Balena Documentation) and curl-ing the API from the service with the following:
curl -X GET "$BALENA_API_URL/v6/device?\$filter=startswith(uuid,'$BALENA_DEVICE_UUID')" --compressed --silent -H "Authorization: B
earer $BALENA_API_KEY"
You’ll receive a JSON response which contains os_variant, which you can extract with a package like jq. Let us know if this works for you!
Regards,
Christina
Hi, @cywang117
Thanks for your quick reply!
Hmm, no reply from the curl command above… Seems my supervisor version is too old?
root@balena:/usr/src/app# curl -X GET --header "Content-Type:application/json" "$BALENA_SUPERVISOR_ADDRESS/v1/device?apikey=$BALENA_SUPERVISOR_API_KEY"
{"api_port":48484,"ip_address":"10.0.1.69","os_version":"balenaOS 2.80.8+rev1","mac_address":"B8:27:EB:77:43:65","supervisor_version":"12.8.8","update_pending":false,"update_failed":false,"update_downloaded":false,"commit":"9424da8ca143882cb5a0466ed3c73f12","status":"Downloaded","download_progress":null}
I cannot upgrade its version as we are using openBalena instead of balenaCloud…
From which version is the /v6/device API supported?
Cheers,
Shane.
Sorry, I should clarify - the above cURL is for the balena cloud API, not the Supervisor API. The Supervisor API is available on each device and is accessible from containers if you use the io.balena.features.supervisor-api label. v12.8.8 is relatively new as well.
When you were running the command, did you have the io.balena.features.balena-api label set for the service you’re using to query your openBalena server?
Also, what version of openBalena are you using? Thanks!
Hi, @cywang117
Yes, I had enabled balena-api and was able to get the device details. please check above.
And the openBalena server - I am using 3.4.0 at the moment.
Cheers,
Shane.
Hi Shane,
I’m confused about what you mean regarding the device details snippet you sent - that query was made to the Supervisor API, which is made available with the label of io.balena.features.supervisor-api. It’s different than the balena-api label (io.balena.features.balena-api) which is needed to query the /v6/deviceendpoint from a container.
To clarify, since you’ve set the io.balena.features.balena-api label for your service already, are you following these steps:
balena exec -it YOUR_SERVICE_WITH_BALENA_API_LABEL /bin/bash- To check that the balena-api label was activated for your service, you can run
printenv | grep 'BALENA'. You should seeBALENA_API_URLcorresponding to your openBalena API server,BALENA_DEVICE_UUID, andBALENA_API_KEY. - Run the previous command
curl -X GET "$BALENA_API_URL/v6/device?\$filter=startswith(uuid,'$BALENA_DEVICE_UUID')" --compressed --silent -H "Authorization: Bearer $BALENA_API_KEY"
Additionally, /v6/devices should be accessible from openBalena version 3.4.0, as it’s quite new.
Apologies for the confusion! 
Regards,
Christina
Oh, I am confused! lol
Yeah, will give it a try soon and get back to you!
Thanks!
Thanks! Let us know if it works for you.
@cywang117
Hmm, no reply from the command… But I can see the env variables inside the container with printenv | grep BALENA command…
Any idea?
Hi there, quite strange that it’s simply returning nothing… Perhaps try running the curl command withou the --silent option and see if it gives us an error message
Oh, yes. I had to add --insecure parameter to ignore the SSL issue. Thanks!