Skip to content

Conversation

@cywang117
Copy link
Contributor

This allows Supervisors that support Supervisor-managed OS upgrades to trigger a HUP.

See: https://balena.fibery.io/Work/Improvement/API-and-SDK-changes-for-supervisor-hostOS-updates-2348
Change-type: minor

This allows Supervisors that support Supervisor-managed OS upgrades
to trigger a HUP.

See: https://balena.fibery.io/Work/Improvement/API-and-SDK-changes-for-supervisor-hostOS-updates-2348
Change-type: minor
Signed-off-by: Christina Ying Wang <[email protected]>
(request.values.is_pinned_on__release !== undefined ||
request.values.belongs_to__application != null ||
request.values.device_name != null) &&
request.values.device_name != null ||
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the supervisor only updated the device name for containers when they were receiving other updates? In which case there's no point to trigger a supervisor update check in that case as it would just be unnecessary load

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Supervisor stores the most up-to-date device name in its config table of its sqlite database though, and uses this for SV API's /v2/device/name calls. You're right though that BALENA_DEVICE_NAME_AT_INIT env var for services only changes when starting up the service, and changing the name doesn't result in a service restart by itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants