restructures config file, and adds all code necessary to interact with a remote controller. Tests for the above, of course.
The structure of the config matches identically what is expected in the body of a config sent from a remote controller. The same structs and tests can handle both local and remote provided.
At some point, this definition likely should be driven from an API definition in the API repo. The API repo defines all of the API between a databacker instance and a cloud controller, only one part of which is the config. The API there is defined in openapi3 format, with the content of the config defined in a component schema. Neither the API itself nor the content schema is adopted yet by mysql-backup. mysql-backup solely understands, "GET config" and nothing else. It does not yet send telemetry to the remote controller.
The initial challenges for just the config are:
the multiple options for a config file, based on what the kind is (remote vs local)
the specific UnmarshalYAML() functions on the structs, which allow us to handle these cases and do custom unmarshaling. There are 2 of these: Config and Storage. Storage is easier, as we could post-process it, it need not be part of the API. Config is harder, focused on how it is able to handle the 2 kinds of structs.
restructures config file, and adds all code necessary to interact with a remote controller. Tests for the above, of course.
The structure of the config matches identically what is expected in the body of a config sent from a remote controller. The same structs and tests can handle both local and remote provided.
At some point, this definition likely should be driven from an API definition in the API repo. The API repo defines all of the API between a databacker instance and a cloud controller, only one part of which is the config. The API there is defined in openapi3 format, with the content of the config defined in a component schema. Neither the API itself nor the content schema is adopted yet by mysql-backup. mysql-backup solely understands, "GET config" and nothing else. It does not yet send telemetry to the remote controller.
The initial challenges for just the config are:
kind
is (remote
vslocal
)UnmarshalYAML()
functions on the structs, which allow us to handle these cases and do custom unmarshaling. There are 2 of these:Config
andStorage
.Storage
is easier, as we could post-process it, it need not be part of the API.Config
is harder, focused on how it is able to handle the 2 kinds of structs.