Project

General

Profile

Actions

Bug #3644

closed

Change Request can't be validated if it concerns groups

Added by Vincent MEMBRÉ almost 11 years ago. Updated over 10 years ago.

Status:
Released
Priority:
1
Category:
Web - Maintenance
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

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

Actions #1

Updated by Nicolas PERRON almost 11 years ago

  • Project changed from 24 to Rudder
Actions #2

Updated by Vincent MEMBRÉ almost 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
  • Target version set to 2.6.3
Actions #3

Updated by Vincent MEMBRÉ almost 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.

https://github.com/Normation/rudder/pull/229

Actions #4

Updated by Vincent MEMBRÉ almost 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

Actions #5

Updated by Vincent MEMBRÉ almost 11 years ago

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100
Actions #6

Updated by Anonymous almost 11 years ago

Actions #7

Updated by Nicolas PERRON over 10 years ago

  • Subject changed from Can't validate Change requests about groups to Change Request can't be validated if it concerns groups
Actions #8

Updated by Nicolas PERRON over 10 years ago

  • Category changed from Web - Nodes & inventories to Web - Maintenance
Actions #9

Updated by Nicolas PERRON over 10 years ago

  • Status changed from Pending release to Released
Actions #10

Updated by Nicolas PERRON over 10 years ago

This bug has been fixed in Rudder 2.6.3, which was released today.
Check out:

Actions #11

Updated by Andrew Cranson over 10 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.

Actions #12

Updated by Nicolas CHARLES over 10 years ago

  • Assignee changed from François ARMAND to Nicolas CHARLES

I'll have a look at it, thank you !

Actions #13

Updated by Nicolas CHARLES over 10 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 ?

Actions #14

Updated by Andrew Cranson over 10 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:

  1. Going to an existing directive (iptables technique)
  2. Editing the directive (it's assigned to the 'root policy server' group)
  3. Clicking 'save'
  4. 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.

Actions #15

Updated by Andrew Cranson over 10 years ago

Sorry, I meant Nicolas of course.

Actions #16

Updated by Nicolas CHARLES over 10 years ago

Sorry, I've been delayed; i'm working on it !

Actions #17

Updated by Nicolas CHARLES over 10 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

Could you list exactly:
  1. the name of the technique on which the directive you are mofiying is based
  2. the exact modification you are doing in the directive (name of field, previous value, new value)
  3. if the directive is used in several rules
  4. the change request detail (the diff)
  5. 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 :/

Actions

Also available in: Atom PDF