Birectional communication of libdnf5 actions plugin with running processes - "json" mode #1642
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
jrohel
force-pushed
the
feature/libdnf_actions_plugins_json
branch
from
4925421
to
e7c3856
Compare
…tion If the key contains a dot sign, it is a repository option. Improved detection -> ignoring dots after equals sign. On the other hand, value_patter is supported only for repository options. Parsed pattern: <repoid_pattern>.<option_name>[=<value_pattern>] Bump version to 1.1.1
Option "mode" defines communication model between actions plugin and process.
Introduces 2 modes of communication: "plain" and "json".
"mode=plain" - Original and default communication model.
Parameters are passed to the process only by arguments when it starts.
Arguments may contain variables that are substituted before the process is
started. A process can modify libdnf5 settings (main configuration, repository
configuration, variables) and plugin actions variables by writing to standard
output.
Output line format:
- tmp.<actions_plugin_variable_name>=<value> - sets the value of action plugins
variable <actions_plugin_variable_name>
- tmp.<actions_plugin_variable_name> - removes the action plugins variable if
it exists
- conf.<option_name>=<value> - sets the value of option <option_name> in
the base configuration
- conf.<repoid_pattern>.<option_name>=<value> - sets the value of option
<option_name> in the matching repositories
- var.<variable_name>=<value> - sets value of the variable <variable_name>
"mode=json" - Newly introduced communication model.
Parameters can be passed to the process before it starts using arguments just
like in "plain" mode. This mode adds bidirectional communication between
the actions plugin and the process. This is request/response communication.
The process sends requests and the actions plugin sends responses. The process
writes requests to the standard output and reads responses from the standard
input. The communication will be implemented later and will use JSON format.
This is a preliminary commit.
jrohel
force-pushed
the
feature/libdnf_actions_plugins_json
branch
3 times, most recently
from
a220ac0
to
b2a177e
Compare
jrohel
force-pushed
the
feature/libdnf_actions_plugins_json
branch
from
b2a177e
to
12ee2b5
Compare
kontura
reviewed
Sep 18, 2024
|
I believe a docs update is needed and I assume it will be done in a follow up PR. |
Processes send requests and the actions plugin responds.
- Request format:
{"op":"<operation>", "domain":"<domain>", "args":{<op_domain_spec_args>}}
"domain" is ignored in the case of the "log" operation.
- Response format:
{"op": "reply", "requested_op":"<op_from_request>", "domain":
"<domain_from_request>", "status": "OK", "return":{<data>}}
{"op": "reply", "requested_op":"<op_from_request>", "domain":
"<domain_from_request>", "status": "ERROR", "message":"<error message>"}
"return" is not included in the response to a request for a "log"
operation.
If the JSON request is unparsable - a syntax error or incomplete message,
or the response cannot be written, the action plugin closes both communication
pipes. The process must terminate if the communication pipes are closed.
If an error occurs while processing a request from a process,
the location of the hook definition is added to the log message.
e.g. `Syntax error from hook in file "{}" on line {}:`
For example, the "get" operation for "trans_packages" is only allowed for the "pre_transaction" and "post_transaction" hooks.
To ensure the release of resources after an exception.
jrohel
force-pushed
the
feature/libdnf_actions_plugins_json
branch
from
12ee2b5
to
a0b976f
Compare
|
The failing tests are not related. |
Merged
via the queue into
rpm-software-management:main
with commit Sep 20, 2024
877f855
16 of 20 checks passed
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.
Closes: #1538
Introduces a "mode" option in the hook handler definition.
Option "mode" defines communication model between actions plugin and process.
Introduces 2 modes of communication: "plain" and "json".
"mode=plain" - Original and default communication model.
Parameters are passed to the process only by arguments when it starts. Arguments may contain variables that are substituted before the process is started. A process can modify libdnf5 settings (main configuration, repository configuration, variables) and plugin actions variables by writing to standard
output.
Output line format:
tmp.<actions_plugin_variable_name>=<value>- sets the value of action plugins variable<actions_plugin_variable_name>-
tmp.<actions_plugin_variable_name>- removes the action plugins variable if it existsconf.<option_name>=<value>- sets the value of option <option_name> in the base configurationconf.<repoid_pattern>.<option_name>=<value>- sets the value of option <option_name> in the matching repositoriesvar.<variable_name>=<value>- sets value of the variable <variable_name>"mode=json" - Newly introduced communication model.
Parameters can be passed to the process before it starts using arguments just like in "plain" mode. This mode adds bidirectional communication between the actions plugin and the process. This is request/response communication.
The process sends requests and the actions plugin sends responses. The process writes requests to the standard output and reads responses from the standard input.
Processes send requests and the actions plugin responds:
{"op":"<operation>", "domain":"<domain>", "args":{<op_domain_spec_args>}}"domain" is ignored in the case of the "log" operation.
Response format:
{"op": "reply", "requested_op":"<op_from_request>", "domain": "<domain_from_request>", "status": "OK", "return":{<data>}}{"op": "reply", "requested_op":"<op_from_request>", "domain": "<domain_from_request>", "status": "ERROR", "message":"<error message>"}"return" is not included in the response to a request for a "log"
operation.
If the JSON request is unparsable - a syntax error or incomplete message, or the response cannot be written, the action plugin closes both communication pipes. The process must terminate if the communication pipes are closed.