Project

General

Profile

Actions

Bug #5685

closed

Raise errors if there's issues with a technique created with ncf-builder

Added by Florian Heigl about 10 years ago. Updated over 7 years ago.

Status:
Rejected
Priority:
1 (highest)
Assignee:
-
Category:
Web - Technique editor
Target version:
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
User visibility:
Getting started - demo | first install | level 1 Techniques
Effort required:
Priority:
0
Name check:
Fix check:
Regression:

Description

Just found this one in our logs


[2014-10-22 20:40:29] ERROR com.normation.cfclerk.services.impl.GitTechniqueReader - Ignoring technique '/ncf_techniques/RPM_Validation/1.0/metadata.xml' because the descriptor file is malformed. Error message was: Unexpected issue with the descriptor file /ncf_techniques/RPM_Validation/1.0/metadata.xml at line 9, column 27: The entity name must immediately follow the '&' in the entity reference.

Such messages would really need to be made visible in the NCF Editor, when you hit "save".

I was working on another technique which simply would not get stored properly, traced it to the above error blocking things.

Again, this is not about one tech blocking newer ones
Not about the the ability to store broken techniques
Just about not raising an error.

In a multiuser env it's most important that people can raise their hand and ask for help. (they have to know it happened!)

Edit: the solution to that particular problem need a synchrone technique reload or a message bus (see also #4828)


Related issues 4 (0 open4 closed)

Related to Rudder - Bug #5828: Missing st fileRejectedNicolas CHARLES2014-11-26Actions
Related to Rudder - Bug #7560: Reload technique API call must be synchroneReleasedVincent MEMBRÉ2015-12-08Actions
Related to Rudder - Bug #4828: Updating Techniques with error says on the Web Interface that everything is fine, even if it's notResolvedActions
Blocked by Rudder - Bug #5678: ncf api doesn't report hooks errorsRejectedActions
Actions #1

Updated by Matthieu CERDA about 10 years ago

  • Project changed from 41 to Rudder
  • Description updated (diff)
  • Category set to Web - Technique editor
  • Status changed from New to 8
  • Assignee set to François ARMAND
  • Priority changed from N/A to 2
  • Target version set to 2.11.4

Thanks for the report Florian :)

It looks like a Rudder / ncf integration issue, I'm giving this to FAR for evaluation.

Actions #2

Updated by François ARMAND about 10 years ago

  • Priority changed from 2 to 1 (highest)

A non valide technique should not block other (and that's why there is the message).

But I understand the problem, and clearly, such an important message should not get burried in logs.

Changing priority to 1, because without undestanding easily what's going wrong, users hate developers, and I wanna be loved of course, because of egocentrism of devs. And more seriously, because users don't use softwares that don't explain what's wrong with them.

Actions #3

Updated by François ARMAND about 10 years ago

  • Subject changed from Raise errors if there's issues with a technique to Raise errors if there's issues with a technique created with ncf-builder

Ho, and it must have some bug in the code that generates metadata.xml from ncf techniques.

Florian, I didn't saw a bug about that (perhaps I just missed it, if so - sorry! Just give me the link).
Could you help use find it by describing how you reach the point where a technique built with ncf-builder had a syntaxe error ?

Thanks

Actions #4

Updated by Florian Heigl about 10 years ago

Hi,

I think that it was this one. I made the mistake to give it a slightly different name when creating a directive of it, took me forever to get around that. :)

@
  1. /var/rudder/configuration-repository/ncf/50_techniques/SUSE_RPM_Postconfig # cat SUSE_RPM_Postconfig.cf
  2. @name SUSE RPM Postconfig
  3. @description
  4. @version 1.0

bundle agent SUSE_RPM_Postconfig {
methods:
"method_call" usebundle => command_execution("/usr/sbin/rcrpmconfigcheck"),
ifvarclass => "any";
}
@

Note:
This surely looks harmless. Looking for the xml file next.

Actions #5

Updated by Florian Heigl about 10 years ago

Very confused.

I suppose I had deleted that thing after I found the problem. Or something. And it's still somewhere stuck in the config :)

addition:
@
commit 9be3798cda6855401bf986582825431d22479d80
Author: root <root@zzzzz>
Date: Sun Oct 5 00:21:50 2014 +0200

delete my_technique

commit aa44a077e4a6137f41af9dc8d119c2762206abbd
Author: admin <email not set>
...skipping...
Commit meta Technique RPM_Validation

commit 22ffa55f0b2c32d7ec55f6540bdb8599be1cd0a8
Author: ncf API <ncf-api-venv@zzzzz>
Date: Sat Oct 4 23:16:19 2014 +0200

Commit ncf Technique "RPM_Validation" in Rudder

commit 7abd38cb8c6dfb0e636d8c2bd8292739a30c9093
Author: ncf API <ncf-api-venv@zzzzz>
Date: Sat Oct 4 23:16:13 2014 +0200

Commit meta Technique SUSE_RPM_Postconfig
@
Git status shows I deleted it:
@
  1. deleted: ../../ncf/50_techniques/RPM_Validation/RPM_Validation.cf
    @

Francois I think this is something for when we have full support so I can let you poke around on the system.
I will try to restore that technique and identify where it is still dangling around.

What I pasted in Comment #4 can be ignored.

Actions #6

Updated by François ARMAND about 10 years ago

Thanks for all the information.

We are looking for how to display the relevant messages in ncf-builder.

Actions #7

Updated by Vincent MEMBRÉ about 10 years ago

  • Target version changed from 2.11.4 to 2.11.5
Actions #8

Updated by Vincent MEMBRÉ about 10 years ago

  • Target version changed from 2.11.5 to 2.11.6
Actions #9

Updated by Vincent MEMBRÉ almost 10 years ago

  • Target version changed from 2.11.6 to 2.11.7
Actions #10

Updated by Vincent MEMBRÉ almost 10 years ago

  • Target version changed from 2.11.7 to 2.11.8
Actions #11

Updated by Vincent MEMBRÉ almost 10 years ago

  • Target version changed from 2.11.8 to 2.11.9
Actions #12

Updated by Vincent MEMBRÉ almost 10 years ago

  • Target version changed from 2.11.9 to 2.11.10
Actions #13

Updated by François ARMAND over 9 years ago

  • Reproduced set to No

Some follow-up on that one: now that http://www.rudder-project.org/redmine/issues/5866 is released, we do have a lot more of errors handled in ncf-builder, and displayed to the user.

That reported error on that ticket is still NOT displayed because the problem is at the Rudder internal API that reloads technique: the reload is asynchrone, and the API response is just "ok" (meaning: ok, I'm going to reload techniques, no pb !).

So we need a new "reload technique" API that is synchrone AND return the actual result of the technique reloading to be able to do that.

Actions #14

Updated by Benoît PECCATTE over 9 years ago

  • Status changed from 8 to New
Actions #15

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 2.11.10 to 2.11.11
Actions #16

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 2.11.11 to 2.11.12
Actions #17

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 2.11.12 to 2.11.13
Actions #18

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 2.11.13 to 2.11.14
Actions #19

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 2.11.14 to 2.11.15
Actions #20

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 2.11.15 to 2.11.16
Actions #21

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 2.11.16 to 2.11.17
Actions #22

Updated by François ARMAND about 9 years ago

  • Related to Bug #7560: Reload technique API call must be synchrone added
Actions #23

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 2.11.17 to 2.11.18
Actions #24

Updated by Vincent MEMBRÉ almost 9 years ago

  • Target version changed from 2.11.18 to 2.11.19
Actions #25

Updated by Vincent MEMBRÉ almost 9 years ago

  • Target version changed from 2.11.19 to 2.11.20
Actions #26

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.20 to 2.11.21
Actions #27

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.21 to 2.11.22
Actions #28

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.22 to 2.11.23
Actions #29

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.23 to 2.11.24
Actions #30

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 2.11.24 to 308
Actions #31

Updated by Vincent MEMBRÉ over 8 years ago

  • Target version changed from 308 to 3.1.14
Actions #32

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.14 to 3.1.15
Actions #33

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.15 to 3.1.16
Actions #34

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.16 to 3.1.17
Actions #35

Updated by Vincent MEMBRÉ about 8 years ago

  • Target version changed from 3.1.17 to 3.1.18
Actions #36

Updated by Vincent MEMBRÉ almost 8 years ago

  • Target version changed from 3.1.18 to 3.1.19
Actions #37

Updated by François ARMAND over 7 years ago

  • Description updated (diff)
  • Severity set to Major - prevents use of part of Rudder | no simple workaround
  • User visibility set to Getting started - demo | first install | level 1 Techniques
  • Priority set to 0
Actions #38

Updated by François ARMAND over 7 years ago

  • Related to Bug #4828: Updating Techniques with error says on the Web Interface that everything is fine, even if it's not added
Actions #39

Updated by François ARMAND over 7 years ago

  • Description updated (diff)
Actions #40

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.19 to 3.1.20
Actions #41

Updated by Jonathan CLARKE over 7 years ago

  • Assignee deleted (François ARMAND)
Actions #42

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.20 to 3.1.21
Actions #43

Updated by Vincent MEMBRÉ over 7 years ago

  • Target version changed from 3.1.21 to 3.1.22
Actions #44

Updated by Benoît PECCATTE over 7 years ago

  • Status changed from New to Rejected

This is a duplicate of #4828 since the remaining problem is this technique reload api is asynchronous.

Actions

Also available in: Atom PDF