Rudder

Applied in changeset f2ce97b27bc2a05500d5776ac849291779bb1ca4.

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/

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.

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 ?

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.

Sorry, I meant Nicolas of course.

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

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

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 :/