Bug #13609: Change request must not be saved when no validation is needed - Rudder - Issue Tracker

Actions

Copy link

Bug #13609

closed

Change request must not be saved when no validation is needed

Added by François ARMAND about 6 years ago. Updated about 6 years ago.

Status:

Released

Priority:

N/A

Assignee:

Vincent MEMBRÉ

Category:

Web - Config management

Target version:

5.0.1

Pull Request:

https://github.com/Normation/rudder/p...

Severity:

UX impact:

User visibility:

Effort required:

Priority:

Name check:

Fix check:

Regression:

Description

As found in #13567, we have an impedance mismatch between change request service and their repository.

When the workflow service is enable and the change does not trigger a change request, we have:

- A modification is made
- a change request is created by ChangeRequestService#createChangeRequestFromGlobalParameter (and other) and saved in the current enable workflow repository => the jdbc one,
- then we start the workflow, we see that no validation is needed, and we call NoWorkflow workflow, which try to delete the CR from its own repos (the inmemory one)
- and of course, that does not remove the CR from postgres.

If we use the same repos everywhere, we get a `IllegalArgumentException("This a developer error. Please contact rudder developer, saying that they call unemplemented deleteChangeRequest")` because we forbid deletion from JDBC (for auditing reason).

So, we need to NOT save the change request in the service, but in the first step of the workflow (if needed).

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by François ARMAND about 6 years ago

Status changed from New to In progress

Actions

Copy link

Updated by François ARMAND about 6 years ago

So, today the change request is saved in `ChangeRequestServiceImpl#saveAndLogChangeRequest` which is used in all `ChangeRequestService#{createChangeRequestFromDirective, createChangeRequestFromRules, etc}`.

So if we have the "no workflow" wrkflow service, we create the change and save it, then delete it in the workflow. That's strange.
I believe the idea was to be able to split appart "change requests", which are a Rudder concept, and "workflows", which can be externalized. But the scoping does not seems right. In all case, if we rely on some external workflow service, we will need some glue to make it conform to Rudder. We can manage the creation/update of change request at that place.
Or we could have changeRequestService that handle the whole process, totally hiding the underlying steps and implementation from the user.

So: saveAndLogChangeRequest will be moved in TwoValidationStepsWorkflowServiceImpl (in plugin) along with JdbcRepository, which will lead to an even simpler Rudder, and in the long run a real separation of workflow impl / Rudder.

In the short term, it means a breaking API change for that plugin.

Actions

Copy link