Add support for remote barman config-update execution
#89
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So far we had only operations related with Barman servers in the API: * `RecoveryOperation`: to perform a `barman recover` of a Barman server * `ConfigSwitchOperation`: to perform a `barman config-switch` to a Barman server However, we intend to add an operation to the API which is performed at the Barman instance level (global), not to a specific Barman server: the `ConfigModelOperation`. With that in mind this initial commit changes the classes below so we will be able to create Barman instance operations: * `OperationServer`: turn `server_name` argument optional. When it is `None`, that is considered an instance operation. Thus, the `job` and `output` files will be written under the Barman home in that case instead of under a Barman server directory * `Operation`: turn `server_name` argument optional, so it creates `OperationServer` accrodingly Unit tests changed accordingly, so we check both server and instance operations. Follow-up commits to come, which will implement new endpoints to the API and the `ConfigModelOperation`. References: BAR-126. Signed-off-by: Israel Barth Rubio <israel.barth@enterprisedb.com>
This commit fixes the following couple issues reported by `pyright`: ``` pg_backup_api/pg_backup_api/server_operation.py pg_backup_api/pg_backup_api/server_operation.py:634:13 - error: Expression of type "list[str | None]" cannot be assigned to return type "List[str]" Type "str | None" cannot be assigned to type "str" "None" is incompatible with "str" (reportGeneralTypeIssues) pg_backup_api/pg_backup_api/server_operation.py:754:16 - error: Expression of type "list[str | None]" cannot be assigned to return type "List[str]" "list[str | None]" is incompatible with "List[str]" Type parameter "_T@list" is invariant, but "str | None" is not the same as "str" Consider switching from "list" to "Sequence" which is covariant (reportGeneralTypeIssues) ``` References: BAR-126. Signed-off-by: Israel Barth Rubio <israel.barth@enterprisedb.com>
So far we had only endpoints for handling Barman server operations. This commit is a preparation step before implementing the first instance operation. As part of the work we added a couple new endpoints to the API: * `/operations/<operation_id>`: used to get the status of an instance operation -- similar to what we have for server operations through `/servers/<server_name>/operations/<operation_id>`; * `/operations`: used to get a list of or instance operations, or to create a new instance operation -- similar to what we have for server operations through `/servers/<server_name>/operations`. The handling of `POST` requests to `/operations` is only returning a dummy message for now, as we still need to implement the first instance operation. Unit tests were modified accordingly. References: BAR-126. Signed-off-by: Israel Barth Rubio <israel.barth@enterprisedb.com>
This commit adds the class `ConfigModelOperation` and the command `pg-backup-api config-model`. We still need to define the final implementation of the command in Barman (`barman config-model`), so we can back here and update this branch with changes in the code and unit tests. References: BAR-126. Signed-off-by: Israel Barth Rubio <israel.barth@enterprisedb.com>
We initially designed a command in Barman called `barman config model` to create and update models. However, as part of BAR-128 we ended up implementing `barman config-update` which is able to handle both server and models. This commit reflects that change in the name of the command, and also implements the actual logic for listening on the pg-backup-api endpoint and properly calling the Barman command. References: BAR-126. Signed-off-by: Israel Barth Rubio <israel.barth@enterprisedb.com>
barthisrael
changed the title
barthisrael
changed the title
barman config-update execution
barthisrael
changed the title
barman config-update executionbarman config-update execution
References: BAR-126. Signed-off-by: Israel Barth Rubio <israel.barth@enterprisedb.com>
Signed-off-by: Israel Barth Rubio <israel.barth@enterprisedb.com>
gcalacoci
approved these changes
Jan 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So far we had only operations related with Barman servers in the API:
RecoveryOperation: to perform abarman recoverof a Barman serverConfigSwitchOperation: to perform abarman config-switchto a Barman serverHowever, we needed to add an operation to the API which is performed at the Barman instance level (global), not to a specific Barman server: the
ConfigUpdateOperation.With that in mind this PR changes the classes below so we will be able to create Barman instance operations:
OperationServer: turnserver_nameargument optional. When it isNone, that is considered an instance operation. Thus, thejobandoutputfiles will be written under the Barman home in that case instead of under a Barman server directoryOperation: turnserver_nameargument optional, so it createsOperationServeraccordinglyWe also added a couple new endpoints to the API, so we can handle instance operations:
/operations/<operation_id>: used to get the status of an instance operation -- similar to what we have for server operations through/servers/<server_name>/operations/<operation_id>;/operations: used to get a list of or instance operations, or to create a new instance operation -- similar to what we have for server operations through/servers/<server_name>/operations.The
BarmanConfigUpdateoperation has been created and uses the above API endpoints.Unit tests changed accordingly, so we check both server and instance operations, including the introduced operation.
References: BAR-126.