Project

General

Profile

Actions

Bug #3198

closed

Sometimes, accepting a new version of a Policy Template fails in Rudder 2.3

Added by Nicolas CHARLES almost 12 years ago. Updated over 11 years ago.

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

Description

As in http://www.rudder-project.org/redmine/issues/3039, I created a new version for a Policy Template of checkGenericFileContent, accepted it within Rudder, and then I have the following stacktrace when trying to access the directive

18:56:34.260 [qtp1706427008-62] ERROR net.liftweb.http.LiftRules - Exception being returned to browser when processing Req(List(F1156367130962LYEQ2E, F1156367130
951NMU3MR, F1156367130956QMYWSC, F1156367130967EHLQ53, F1156367130943UYB5BX, F1156367130968UA5EO5, F1156367130963R0Y4EI, F1156367130971GWWOJZ, F1156367130953XULA
DC, F1156367130950SHGYDF, F1156367130945QE41RC, F1156367130972J0LRCS, F1156367130964WKPFFJ, F11563671309582GDLQT, F11563671309650HTWLC, F1156367130947NK5NZN, F11
563671309664E4PSU, F1156367130952ASR4BL, F1156367130960CEL5K2, F1156367130957DS4MTQ, F1156367130961JGOY5T, F1156367130970BFXSLJ, F1156367130955AI1Q2T, F115636713
0954T45TXW, F1156367130959OJMHYL, F1156367130973V0EIKL, F1156367130969MFBBMP, zF1156367130976UYRZVN, F1156367130949KKQCMM), Map(F11563671309582GDLQT -> List(^Hel
lo World), F1156367130952ASR4BL -> List(false), F1156367130957DS4MTQ -> List(deleteme.*), F1156367130970BFXSLJ -> List(false), F1156367130960CEL5K2 -> List(false
), F1156367130964WKPFFJ -> List(true, false), F1156367130955AI1Q2T -> List(true, false), F1156367130950SHGYDF -> List(/tmp/bug2819.txt), F1156367130951NMU3MR ->
List(false), F1156367130945QE41RC -> List(), F1156367130969MFBBMP -> List(true, false), F1156367130954T45TXW -> List(false), F1156367130953XULADC -> List(true, f
alse), F1156367130947NK5NZN -> List(Quality & Assurance on Techniques: Bug reported on Enforce a file content.

It seems that replacing a line with this one is bogus.), F1156367130973V0EIKL > List(), F1156367130968UA5EO5 -> List(false), F1156367130949KKQCMM -> List(PPWVBZ
CBOWDWJFGK303U), F1156367130943UYB5BX -> List(QA - Bug 2819: Replacing line using regexp fails), F11563671309664E4PSU -> List(true, false), F1156367130956QMYWSC
> List(I'm a bug.

O RLY ?), zF1156367130976UYRZVN -> List(_), F1156367130971GWWOJZ -> List(false), F1156367130962LYEQ2E -> List(root), F1156367130963R0Y4EI -> List(true, false), F
1156367130961JGOY5T -> List(root), F1156367130959OJMHYL -> List(), F11563671309650HTWLC -> List(false), F1156367130967EHLQ53 -> List(false), F1156367130972J0LRCS
-> List(false)), ParsePath(List(ajax_request, F1156367130208CTJTP2, index),,true,true), /rudder, PostRequest, Full(application/x-www-form-urlencoded; charset=UT
F-8))
java.util.NoSuchElementException: key not found: GENERIC_FILE_CONTENT_ENFORCE_CREATE_ONLY_BOOLEAN
at scala.collection.MapLike$class.default(MapLike.scala:224) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.immutable.HashMap.default(HashMap.scala:36) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.MapLike$class.apply(MapLike.scala:135) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.immutable.HashMap.apply(HashMap.scala:36) ~[scala-library-2.9.0-1.jar:na]
at com.normation.rudder.domain.policies.SectionVal$$anonfun$2.apply(PolicyInstance.scala:155) ~[rudder-core-0.10.1-SNAPSHOT.jar:na]
at com.normation.rudder.domain.policies.SectionVal$$anonfun$2.apply(PolicyInstance.scala:154) ~[rudder-core-0.10.1-SNAPSHOT.jar:na]
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.immutable.List.foreach(List.scala:45) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.TraversableLike$class.map(TraversableLike.scala:194) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.immutable.List.map(List.scala:45) ~[scala-library-2.9.0-1.jar:na]
at com.normation.rudder.domain.policies.SectionVal$.buildMonoSectionWithMultivaluedParent$1(PolicyInstance.scala:154) ~[rudder-core-0.10.1-SNAPSHOT.jar:n
a]
at com.normation.rudder.domain.policies.SectionVal$$anonfun$9$$anonfun$apply$3.apply(PolicyInstance.scala:200) ~[rudder-core-0.10.1-SNAPSHOT.jar:na]
at com.normation.rudder.domain.policies.SectionVal$$anonfun$9$$anonfun$apply$3.apply(PolicyInstance.scala:199) ~[rudder-core-0.10.1-SNAPSHOT.jar:na]
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.immutable.List.foreach(List.scala:45) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.TraversableLike$class.map(TraversableLike.scala:194) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.immutable.List.map(List.scala:45) ~[scala-library-2.9.0-1.jar:na]
at com.normation.rudder.domain.policies.SectionVal$$anonfun$9.apply(PolicyInstance.scala:199) ~[rudder-core-0.10.1-SNAPSHOT.jar:na]
at com.normation.rudder.domain.policies.SectionVal$$anonfun$9.apply(PolicyInstance.scala:197) ~[rudder-core-0.10.1-SNAPSHOT.jar:na]
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.immutable.Range.foreach(Range.scala:78) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.TraversableLike$class.map(TraversableLike.scala:194) ~[scala-library-2.9.0-1.jar:na]
at scala.collection.immutable.Range.map(Range.scala:43) ~[scala-library-2.9.0-1.jar:na]
at com.normation.rudder.domain.policies.SectionVal$.buildMultiSectionWithoutMultiParent$1(PolicyInstance.scala:197) ~[rudder-core-0.10.1-SNAPSHOT.jar:na]
at com.normation.rudder.domain.policies.SectionVal$$anonfun$12.apply(PolicyInstance.scala:222) ~[rudder-core-0.10.1-SNAPSHOT.jar:na]
at com.normation.rudder.domain.policies.SectionVal$$anonfun$12.apply(PolicyInstance.scala:220) ~[rudder-core-0.10.1-SNAPSHOT.jar:na]
18:56:41.753 [qtp1706427008-65] ERROR net.liftweb.http.LiftRules - Exception being returned to browser when processing Req(List(F1156367130238CXRXUN), Map(F1156367130238CXRXUN -> List(true)), ParsePath(List(ajax_request, F1156367130208CTJTP2, index),,true,true), /rudder, PostRequest, Full(application/x-www-form-urlencoded; charset=UTF-8))

There was no migration occuring, and something strange happened

Francois, could you have a look at this ?


Related issues 1 (0 open1 closed)

Related to Rudder - Bug #3039: This is not possible to edit an Services management Directive after a migration from 2.4.0~beta4 to 2 4.0~rc1ReleasedNicolas PERRONActions
Actions #1

Updated by Nicolas CHARLES almost 12 years ago

Here is what I have for the acceptationTimeStamp {"3.1":"20130109162934.755Z","2.0":"20130109162934.755Z","2.1":"20130109162934.755Z","3.0":"20130109162934.755Z","1.0":"20130109162934.755Z"}

Don't read that, it was the wrong orchestrator

Actions #2

Updated by Nicolas CHARLES almost 12 years ago

Ha, just after adding the PT, I changed the version of a directive to 3.2. Then it broke
Somehow, the directive is in an inconsistent state (i removed the faulty 3.2 afterward). After the removal, I have in my ldap tree {"3.1":"20121121150951.783Z","2.0":"20120717170952.115Z","3.2":"20130115184131.480Z","2.1":"20120717170952.115Z","3.0":"20121120141920.011Z","1.0":"20120717170952.115Z"}

Actions #3

Updated by Matthieu CERDA almost 12 years ago

  • Target version changed from 2.3.10 to 2.3.11
Actions #4

Updated by François ARMAND almost 12 years ago

  • Status changed from 8 to Discussion
  • Assignee changed from François ARMAND to Nicolas CHARLES

I'm not sure I understand what happen here. Do you found an other way to trigger #3039, in Rudder 2.3, and so that means that we need to backport commit 240a1cc4 to that branch? Or is it something else? (in the second case, I don't have any clue about how to reproduce the problem, and so I have no idea about how to start...).

Actions #5

Updated by Matthieu CERDA over 11 years ago

  • Target version changed from 2.3.11 to 2.3.12
Actions #6

Updated by Matthieu CERDA over 11 years ago

  • Target version changed from 2.3.12 to 2.3.13
Actions #7

Updated by Nicolas PERRON over 11 years ago

  • Target version changed from 2.3.13 to 84
Actions #8

Updated by Nicolas PERRON over 11 years ago

  • Target version changed from 84 to 2.4.7
Actions #9

Updated by Nicolas PERRON over 11 years ago

  • Target version changed from 2.4.7 to 2.4.8
Actions #10

Updated by Nicolas PERRON over 11 years ago

  • Status changed from Discussion to Rejected
  • Target version changed from 2.4.8 to 2.4.9

The title suggest this is about Rudder 2.3 so I suppose we can reject this bug.

Actions #11

Updated by Nicolas PERRON over 11 years ago

  • Parent task deleted (#3039)
Actions

Also available in: Atom PDF