This allows to compare the current and target container names and
trigger an `updateMetadata` step if they are different. This allows us
to normalize the container name format with a new supervisor update.
Change-type: minor
The image id is no longer necessary to report the current state since
moving to v3 of the state endpoint and it is only kept for backwards
compatibility for some supervisor API endpoings.
Until now, `imageId` was part of the container name leading to longer
names than desired. This change removes the value from the container
name an modifies queries to look for the value in the image database.
This also removes the imageId from the log stream which should result in
reduced bandwidth usage.
Change-type: minor
The release id is not really necessary for reporting the current state
since v3 (it has been replaced by `releaseUuid`) and is only kept for
backwards compatibility for some supervisor API endpoints.
Until now, the `releaseId` was part o the container name, leading to
longer names than desired. This change removes the value from the
container name and modifies queries to look for the value in the image
database.
Change-type: minor
Relates-to: #2077
The `updateMetadata` step renames the container to match the target
release when the service doesn't change between releases. We have seen
this step fail because of an engine bug that seems to relate to the
engine keeping stale references after container restarts. The only way
around this issue is to remove the old container and create it again.
This implements that workaround during the updateMetadata step to deal
with that issue.
Change-type: minor
Relates-to: balena-os/balena-engine#261
Whenever the Supervisor reports current state, it diffs the current state
with its last reported current state. However, when the Supervisor starts
up, there is no last reported state, since that last report is stored in
process memory. Caching the last report in a location that survives
Supervisor restarts will reduce the current report bandwidth used on startup.
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
Intermediate state is utilized when executing device actions such as a
volume purge. It's a type of state apply, but despite that,
applyInProgress is not true.
Change-type: patch
Signed-off-by: Christina Ying Wang <christina@balena.io>
PR #2217 removed the expose configuration but also caused a regresion
where ports set via the `ports` configuration would no longer get
exposed to the host, despite portmappings being set. This fixes that
issue by exposing only those ports comming from port mappings.
Change-type: patch
The docker EXPOSE directive and corresponding docker-compose `expose`
service configuration serves as documentation/metadata that a container
listens on a certain port that may be used for service discovery but it doesn't
have any real impact on the ability for
other containers on the same network to access the exposed service via
the port. In newer engine implementations, this property may conflict
with other network configurations, and prevent the container from being
started by the docker engine (see #2211).
This PR removes code that would manage the expose property and takes the
property out of the whitelist. A composition with the `expose` property
will result in the log message `Ignoring unsupported or unknown compose fields: expose`.
While this change should not have operational impact, it still removes
a previously supported configuration and as such there is a chance of it
being a breaking change for some applications. For this reason it is
being published as a new major version.
Change-type: major
Closes: #2211
This reverts commit 0c7bad7792, as that
change causes a service restart loop. The supervisor cannot distinguish
between ports exposed via the `EXPOSE` directive and the docker-compose
`expose` property. Because of this, in the case of `network-mode:
service:<...>` the current state and target state never match, leading
to a service restart loop.
Change-type: patch
