Bug #3644
closedChange Request can't be validated if it concerns groups
Description
When creating a change request about a node groups, the webapp says that :
This change request can not be accepted because configuration state was modified since change request creation. Only "decline" action is available.
and is not mergeable anymore, although no changes happenned about this group.
nodes in the original change request were not serialized, so when comparing to datas in LDAP (which has node serialized in it) the group are different.
here are two logs generated in the code :
NodeGroup(NodeGroupId(3f153c38-af55-4346-9240-2ee2121575d0),All linux nodes,,Some({ returnType:'NodeReturnType' with 'And' criteria [node.OS eq Linux] }),true,Set(),true,false) NodeGroup(NodeGroupId(3f153c38-af55-4346-9240-2ee2121575d0),All linux nodes,,Some({ returnType:'NodeReturnType' with 'And' criteria [node.OS eq Linux] }),true,Set(NodeId(36076ea3-281c-480e-be25-1392bfc39b71), NodeId(5ee53fbe-ff96-4606-a78b-5e408cbf77c9)),true,false)
The first one is the original state of the change request (cut from his nodes)
the second one is the real node with his nodes
Updated by Vincent MEMBRÉ over 11 years ago
- Subject changed from can't accept new change request about groups to Can't validate Change requests about groups
- Description updated (diff)
- Category set to Web - Nodes & inventories
- Status changed from New to In progress
- Assignee set to Vincent MEMBRÉ
- Priority changed from N/A to 1 (highest)
- Target version set to 2.6.3
Updated by Vincent MEMBRÉ over 11 years ago
- Pull Request set to https://github.com/Normation/rudder/pull/229
In fact this was happening on non empty dynamic node groups.
This is due to the serialization which remove nodes for dynamic groups.
which leads to difference between the group in LDAP and the serialized groups.
Here is pull request fixing this.
Updated by Vincent MEMBRÉ over 11 years ago
- Status changed from In progress to Pending technical review
- Assignee changed from Vincent MEMBRÉ to François ARMAND
Switching to technical review
Updated by Vincent MEMBRÉ over 11 years ago
- Status changed from Pending technical review to Pending release
- % Done changed from 0 to 100
Applied in changeset 3e77c6fcad972fc7c7663c142f709560a67ed864.
Updated by Anonymous over 11 years ago
Applied in changeset f2ce97b27bc2a05500d5776ac849291779bb1ca4.
Updated by Nicolas PERRON over 11 years ago
- Subject changed from Can't validate Change requests about groups to Change Request can't be validated if it concerns groups
Updated by Nicolas PERRON over 11 years ago
- Category changed from Web - Nodes & inventories to Web - Maintenance
Updated by Nicolas PERRON over 11 years ago
- Status changed from Pending release to Released
Updated by Nicolas PERRON over 11 years ago
This bug has been fixed in Rudder 2.6.3, which was released today.
Check out:
- The release announcement: http://www.rudder-project.org/pipermail/rudder-announce/2013-July/000036.html
- The full ChangeLog: http://www.rudder-project.org/foswiki/bin/view/System/Documentation:ChangeLog26
- Download information: http://www.rudder-project.org/foswiki/Download/
Updated by Andrew Cranson about 11 years ago
I think this problem has returned as I'm getting the same problem (This change request can not be accepted because configuration state was modified since change request creation. Only "decline" action is available.) in 2.7.1 when trying to modify a rule applied to the "Root policy server" group. I can't seem to find the log file you found the logs above to verify if it's exactly the same issue though, could you please point me in the right direction?
I can't verify if this worked in 2.7.0 as we have only just enabled the change request workflow.
Updated by Nicolas CHARLES about 11 years ago
- Assignee changed from François ARMAND to Nicolas CHARLES
I'll have a look at it, thank you !
Updated by Nicolas CHARLES about 11 years ago
Andrew, I cannot reproduce the problem.
I applied a rule to the group system Root policy server; validate the change without problem, then accepted a node, and deployed the change
The log file is in /var/log/rudder/webapp/date_stderrout.log (like /var/log/rudder/webapp/2013_07_31.stderrout.log)
Could it be that you can only decline it because you try to deploy your own change, and didn't set the parameter rudder.workflow.self.deployment to true in the /opt/rudder/etc/rudder-web.properties config file ?
Updated by Andrew Cranson about 11 years ago
Hi Charles,
Unfortunately, it's not that. I checked the parameters (workflow.self.deployment, etc.) and they were fine:
CT-10112-bash-4.1# grep workflow /opt/rudder/etc/rudder-web.properties # If true, the workflow will be activated within Rudder. Every changes in # If true, the workflow will be activated within Rudder. Every changes in rudder.workflow.enabled=true rudder.workflow.self.validation=true rudder.workflow.self.deployment=true
I've just re-run a test and it's the same problem.
There's also nothing logged to /var/log/rudder/webapp/2013_09_04.stderrout.log about this.
Step-by-step, I'm doing this:
- Going to an existing directive (iptables technique)
- Editing the directive (it's assigned to the 'root policy server' group)
- Clicking 'save'
- Clicking 'submit for validation'
It then immediately says:
This change request can not be accepted because configuration state was modified since change request creation. Only "decline" action is available.
It shows the correct creation date: Created on 2013-09-04 14:56 by andrew
Can I provide you with any more information which might help you debug this? I'll be happy to do so.
Updated by Nicolas CHARLES about 11 years ago
Sorry, I've been delayed; i'm working on it !
Updated by Nicolas CHARLES about 11 years ago
I'm afraid I cannot reproduce the issue.
First, I don't have the Iptable technique, I tried with the IPv4 routing management.
I creating a directive, created a rule, in the rule applied this directive to the group root policy server, accepted the changes
Then I tried to modify the parameters of the directive, with success
I tried to change the rule, with success
I rename the directive, with success
- the name of the technique on which the directive you are mofiying is based
- the exact modification you are doing in the directive (name of field, previous value, new value)
- if the directive is used in several rules
- the change request detail (the diff)
- if there are other change request on this directive, or on the rule
I'm sorry for the delay for resolving this bug, but I cannot reproduce it yet :/