Extend information from leapp saved to leappdb #847
Conversation
Thank you for contributing to the Leapp project!Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
To launch regression testing public members of oamg organization can leave the following comment:
Please open ticket in case you experience technical problem with the CI. (RH internal only) Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please consider rerunning the CI by commenting leapp-ci build (might require several comments). If the problem persists, contact leapp-infra. |
dkubek
changed the title
|
/packit copr-build |
This commit combines multiple additions to the leapp database.
First addition is tracking of entity metadata. The `Metadata` model
stores the metadata of entities such as `Actor` or `Workflow`. This data
is stored in a new table `metadata` of the `leapp.db` file.
1. metadata of *discovered* actors.
For an actor, the metadata stored contain:
`class_name` - the name of the actor class
`name` - the name given to the actor
`description` - the actor's description
`phase` - phase of execution of the actor
`tags` - names of any tags associated with an actor
`consumes` - list of all messages the actor consumes
`produces` - list of all messages the actor produces
`path` - the path to the actor source file
2. workflow metadata.
For a workflow, the metadata stored contain:
`name` - name of the workflow
`short_name` - short name of the workflow
`tag` - workflow tag
`description` - workflow description
`phases` - all phases associated with the workflow
Next addition is tracking of dialog question. Previously leapp was not
able to detect the actual question asked from the user as it could be
generated dynamically when actor is called and depend on the
configuration of the user's system.
Last addition includes storing the actor exit status. Exit status is now
saved as an audit event `actor-exit-status`. Exit status 0 represents
successful execution or `StopActorExecution`/`StopActorExecutionError`,
while 1 indicates an unexpected and unhandled exception.
These changes collectively improve the metadata handling capabilities
of, ensuring accurate storage and retrieval of essential information for
various entities.
|
rebased to fix the test execution |
|
@dkubek seems good to me 💯 I will do some testing yet on rhel8 to be sure and I think we can squash&merge it. |
|
/packit copr-build |
There was a problem hiding this comment.
seems to be working like a charm. Manually tested:
- (pre)upgrade 7 -> 8 & 8 -> 9
- update of existing leapp.db to the new format (7, 8)
- run older leapp, install 847 PR build, run it again, check leapp.db
- run downgraded leapp (released one) after new leapp.db has been created already
In all cases it worked without problems.
I've been thinking whether the StopActorExecutionError should be handled as success or fail in the leapp.db as this one is honestly trickey. People who works with leapp.db directly, could be confused by this, but I understand reasoning for this logic. I think it's ok to go this way and in case we realize later we would like to change the behaviour, it should not be problematic to do it any time. Especially before the next upstream release. So merging to enable works on other features that are waiting for this PR.
pirat89
added
the
changelog-checked
Extend leappdb for leapp-inspector
This commit combines multiple additions to the leapp database.
First addition is tracking of entity metadata. The
Metadatamodel stores the metadata of entities such asActororWorkflow. This data is stored in a new tablemetadataof theleapp.dbfile.metadata of discovered actors.
For an actor, the metadata stored contain:
class_name- the name of the actor classname- the name given to the actordescription- the actor's descriptionphase- phase of execution of the actortags- names of any tags associated with an actorconsumes- list of all messages the actor consumesproduces- list of all messages the actor producespath- the path to the actor source fileworkflow metadata.
For a workflow, the metadata stored contain:
name- name of the workflowshort_name- short name of the workflowtag- workflow tagdescription- workflow descriptionphases- all phases associated with the workflowNext addition is tracking of dialog question. Previously leapp was not able to detect the actual question asked from the user as it could be generated dynamically when actor is called and depend on the configuration of the user's system.
Last addition includes storing the actor exit status. Exit status is now saved as an audit event
actor-exit-status. Exit status 0 represents successful execution orStopActorExecution/StopActorExecutionError, while 1 indicates an unexpected and unhandled exception.These changes collectively improve the metadata handling capabilities of, ensuring accurate storage and retrieval of essential information for various entities.