The host-config module exposes the following interfaces: get,
patch, and parse.
`get` gets host configuration such as redsocks proxy configuration
and hostname and returns it in an object of type HostConfiguration.
`patch` takes an object of type HostConfiguration or LegacyHostConfiguration
and updates the hostname and redsocks proxy configuration, optionally
forcing the patch through update locks.
`parse` takes a user input of unknown type and parses it into type
HostConfiguration or LegacyHostConfiguration for patching, erroring if
parse was unsuccessful.
LegacyHostConfiguration is a looser typing of the user input which does
not validate values of the five known proxy fields of type, ip, port,
username, and password. We should stop supporting it in the next
major Supervisor API release.
Change-type: minor
Signed-off-by: Christina Ying Wang <christina@balena.io>
Parses input from PATCH /v1/device/host-config into either
type HostConfiguration, or if LegacyHostConfiguration if
input is of an acceptable shape (for backwards compatibility).
Once input has been determined to be of type HostConfiguration,
we can easily extract ProxyConfig from the object for patching,
stringifying, and writing to redsocks.conf.
Change-type: minor
Signed-off-by: Christina Ying Wang <christina@balena.io>
`stringify` takes a RedsocksConfig, an internal object
representation of the redsocks.conf file, and transforms
it into a valid string that can be written to redsocks.conf.
Signed-off-by: Christina Ying Wang <christina@balena.io>
This is part of the host-config refactor which
enables easier encoding to / decoding from `redsocks.conf`.
Signed-off-by: Christina Ying Wang <christina@balena.io>
This fixes a regression on the supervisor state engine computation
(added on v16.2.0) when
the target state removes a network at the same time that a service
referencing that network is changed. Example going from
```
services:
one:
image: alpine: 3.18
networks: ['balena']
networks:
balena:
```
to
```
services:
one:
image: alpine: latest
```
Would never reach the target state as killing the service in order to
remove the network is prioritized, but one of the invariants in the target state calculation is
to not kill any services until all images have been downloaded. These
two instructions were in contradiction leading to a deadlock.
The fix involves only adding removal steps for services depending on a
changing network or volume if the service container is not being removed
already.
Change-type: patch
This goes in the direction of grouping modules by responsibility. The
api-binder module is the middleware between the device and the backend,
thus the target state polling code makes more sense there.
Change-type: patch
This also deprecates the `getOSVariant` function of the `os-release`
module, as the OS variant are no longer defined in `/etc/os-release`.
Change-type: patch
Instead, add `getBalenaApi` function to api-helper so other modules can
access a balena API instance.
Further reduces circular dependencies to 5
Change-type: patch
This reduces circular dependencies from 250 to 80 by ensuring that
modules that only require types do not import the full module with all
its dependencies.
Change-type: patch
This splits `App`, `Network`, `Service` and `Volume` which used to be
defined as classes into an interface and a class implementation that is
not exported. This will allow to work with just the types in some cases
and prevent circular dependencies when importing.
Change-type: patch
