Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #13609: Change request must not be saved when no validation is needed #2043

Conversation

fanf
Copy link
Member

@fanf fanf commented Oct 9, 2018

https://www.rudder-project.org/redmine/issues/13609

Some explanation: we had a problem because we used to have two repo, one false (in memory) and the real one, for change requests. When we switched the "enable change requests" status, it used to switch the repo.
That does not work in a world where the status also depends of the actual modification.

But that was not the whole problem: we used to always save a change request, even when the validation workflow was not used, so that the only step of the "no workflow" workflow was deleting the saved change in the in memory repos...

So, that PR change the flow of event so that:

  • the change is created,
  • if correct workflow is chosen,
  • if the workflow is a persistent one (the one with validation), its first step is to actually save the change in base,
  • if that happens, it returns the correct change ID,
  • when the workflow status evolves, it is its responsability to change things in DB.

In the end, that allows to completly split appart the "two step validation workflow" from Rudder, including all the repository part. I didn't touched the table creation part, because it has no consequences regarding API version or user or dev experience.

That's a big, very very welcome change. It simplifies a lot what a workflow is and what is needed to make one.

Hereby, change Validation is really independant from Rudder.

* These method allow to get change request impacting a rule/directive/etc.
* Used to display information on them on corresponding update screens.
*/
def getByDirective(id : DirectiveId, onlyPending:Boolean) : Box[Vector[ChangeRequest]]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a question here, why a Vector and not an IndexedSeq ? (or even a Seq/List? )

But don't change it, it's just for my knowledge

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just moved (or copy/pasted) interfaces that where provided elsewhere.

Not sure for the rationnal, but the idea should have been along the line: be precise about what you give to let consumer adpat their behaviors.

// Configuration doesn't give API rights.
// But as nothing manage parameter API, I think it's the correct place
// to add it.
case Configuration.Read => ParameterApi.ListParameters.x :: ParameterApi.ParameterDetails.x :: Nil
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I though Configuration was giving access to all configs (Rules/Directives/Parameters/Techniques), am i wrong ?
So it should provide access to all other element not only parameter

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact it's already like that in 4.3

@Normation-Quality-Assistant
Copy link
Contributor

OK, merging this PR

@Normation-Quality-Assistant Normation-Quality-Assistant merged commit 7a501fe into Normation:branches/rudder/5.0 Oct 11, 2018
@fanf fanf deleted the bug_13609/change_request_must_not_be_saved_when_no_validation_is_needed branch March 15, 2024 10:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants