Project

General

Profile

Actions

User story #5506

closed

Customize Nodes by adding attribute on them

Added by Florian Heigl over 9 years ago. Updated almost 9 years ago.

Status:
Released
Priority:
1
Category:
Web - Nodes & inventories
Target version:
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

Hi,

I'm not sure if this is currently possible. Probably best to describe it now while the idea is raw.

I (think I) would like to sync CMDB data into Rudders LDAP, for example server owners (SAP guys) and usage classes (Testing, Production).
It would be helpful if there could be data for nodes that are still uninventorized and/or pending.

The core points to this:
  1. adding things that are currently not queryable
  2. not getting that info from the node
  3. not having a "lapse" where a new node is there but the data will only upload 10 minutes later
  4. being able to use this info in forming groups
  5. being able to use this info in resulting cf classes

[note from release: the last point was not implemented and will be included along with #3112]

Grepping in the source a little I can see how it's done for the known attributes:

rudder-web/src/main/resources/ldapObjectAndAttributes.properties:ldap.object.networkInterfaceLogicalElement = Network interfaces
rudder-web/src/main/scala/com/normation/rudder/web/services/DisplayNode.scala: { if (showExtraFields) <li><a href={htmlId_#(jsId,"sd_net_")}>Network interfaces</a></li> else NodeSeq.Empty } ::
rudder-web/src/main/scala/com/normation/rudder/web/services/DisplayNode.scala: <li><a href={htmlId_#(jsId,"sd_net_")}>Network interfaces</a></li>

Would the plugin interface of the web app offer a way to do this?


Subtasks 1 (0 open1 closed)

User story #5843: Add key=value node properties, managed via REST API and allowing to build groupReleasedNicolas CHARLES2014-11-27Actions

Related issues 7 (1 open6 closed)

Related to Rudder - User story #3112: Allow to get informations from the node inventory to use them in Directives and ncf techniquesReleasedFrançois ARMANDActions
Related to Rudder - User story #3543: Allow to set key=value tags on nodesResolvedActions
Related to Rudder - Bug #5951: Missing nodekey=value tag API documentationReleasedJonathan CLARKE2014-12-09Actions
Related to Rudder - User story #5821: Proposal: have the possibility to add additional custom information to a nodeRejectedFrançois ARMAND2014-11-26Actions
Related to Rudder - User story #4670: Allows inventories to be augmented by the user with custom propertiesReleasedFrançois ARMANDActions
Related to Rudder - User story #6246: Feature idea: Allow other variable types when using the cfengine variable techniqueNewActions
Related to Rudder - User story #6733: Allow Node properties to be used in directives and ncf techniquesReleased2016-07-20Actions
Actions #1

Updated by Matthieu CERDA over 9 years ago

  • Assignee set to François ARMAND
  • Priority changed from 2 to 4

I think FAR is the best person to know about this.

What do you think, François ?

Actions #2

Updated by François ARMAND over 9 years ago

Hi,

I'm not sure I get it all, so lets rephrase it:

- Feature 1: be able to declare node that are not currently pending.

The goal is to be able to start configure that node (groups, in particular) without having to wait for an inventory.
Workflow will look like:
1/ Create the node with hostname == foo.localhost in the UI (or via API) in "already accepted" state,
2/ Configure groups with that node,
3/ Some time latter, an inventory with hostname "foo.localhost" arrives, automatically merge information with the pre-existing node

Something like #3668

- Feature 2: be able to add data in nodes (say, JSON-like data structure) and use them for groups

The goal here is to be able to add data to a node that are not linked to inventory information.
These data could be set via UI (user editing it) or API (CMDB synchronisation for ex.).

2.1/ Use the data in search to create groups
2.2/ Be able to use the data in Directives (something like parameters, see http://www.rudder-project.org/foswiki/System/ContextedVariables) and/or CFEngines promises

I think we already talked about that to.

Is it that ?

Actions #3

Updated by Florian Heigl over 9 years ago

Hi,

Feature 1:
I'm not sure about the "already accepted state". Personally, I'd like to keep accepting to be a separate task.
I'll check out the script from the linked #3668 tomorrow in lab.
I think that is a good script for fanf's contrib repository!

Feature 2:
yes, sounds right.

Generally, what I'm after is to make sure I can define groups from attributes that are made available from an external source and cannot be influenced from the client side. Harsh example: I don't want someone who broke into a DMZ host be able to turn this host into a server having a vastly different role. Nor should a helpless person in the wrong place be able to turn a "prod" system into a "lab" one.
So I'd like to feed this info into rudder, and have a client see the right info when it is "accepted".
On the other hand, when I feed attributes for 1000s of systems I don't want all of them to be auto-accepted just because of that. :>

Actions #4

Updated by François ARMAND over 9 years ago

I missed to answer to your comment, but OK, the use case is pretty clear.

There is nothing simple (i.e, as in "don't have to understand of bunch Rudder internals and code scala and even some LDAP queries") to do what you want. The logic is trivial, at least if we stay with key=value attributes (because, well, that's just a some attribute to stick to the node).

The hardest part would be the UI, to make it usable, in particular in mass edition - I'm pretty sur one's don't want to go to 200 nodes "details" node to add the same "env=prod" attribute.

Actions #5

Updated by Florian Heigl over 9 years ago

Hi,

I think something like this would always be pushed via external means from CMDB, not from GUI.
Or do you see a use case I don't think of?

Actions #6

Updated by François ARMAND over 9 years ago

I was thinking of all the people not having a CMDB :) Or generally, people wanting to use that to tags node and build there own ontologie for Rudder management only.

But you are right in all case: a first step is to have that available at least from API, it can cover a big part of use cases.

Actions #7

Updated by François ARMAND over 9 years ago

  • Category set to Web - Nodes & inventories
  • Status changed from New to 13
  • Priority changed from 4 to 1
  • Target version set to 3.0.0~beta1

So, we are going to try to put at least some part of that in 3.0:

- being able to define pair of name=value for a node throught the API
- being able to see them (somewhere in node details)
- being able to create groups based on them.

That will allows to start building provisionning scenario from 3.0, and we will be able to easely add UIs after that.

Actions #8

Updated by François ARMAND over 9 years ago

Main architecture ideas:

- we want to be able to latter add node properties defined on the node (for example with script extension)
- we need a "source" information (inventory, user, api, etc) so that we are able to define overriden logic.
- thinking of that, I'm wondering if we should not keep all values, and have the overriden logic at use time (so that we can have "inventory say so, user say so, we keep that")
- it would make sens to have the data live in the "node", not in the inventory. But I think we don't have a sufficiently powerful search engine for that, and other things should also live in the node. So it is acceptable to have them in inventory if not possible elsewhere.
- for the api, I think we need at least:
- set the non empty set of (pair=value)+ (for each of them, add it if not defined, updated else)
- remove given non empty set of (pair=value)+ (if not defined, does nothing, else remove the pair)
- set node pairs to exactly a set of (pair=value)*

Actions #9

Updated by François ARMAND over 9 years ago

So, in fact, adding the key=values in the node and extending the search engine to understand them was easy.

With that, we can put user defined key=values into node, and we will be able to also have some in the inventory latter, and so we will be able to implement an overriding logic easely.

Actions #10

Updated by Jonathan CLARKE over 9 years ago

  • Status changed from 13 to Pending release

This has made it into Rudder 3.0.0~beta1 :)

Actions #11

Updated by Vincent MEMBRÉ over 9 years ago

  • Subject changed from Feature (or just documentation) to add custom attributes to Add custom attributes on Nodes
Actions #12

Updated by Vincent MEMBRÉ over 9 years ago

  • Subject changed from Add custom attributes on Nodes to Customize Nodes by adding attribute on them
Actions #13

Updated by Vincent MEMBRÉ over 9 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.0.0~beta1 which was release on 01/12/2014.

Actions #14

Updated by François ARMAND over 9 years ago

  • Description updated (diff)
Actions #15

Updated by François ARMAND almost 9 years ago

There is a known limitation today (3.0): these properties can't be used in directives ! Only for creating groups.

Actions #16

Updated by François ARMAND almost 9 years ago

  • Related to User story #6733: Allow Node properties to be used in directives and ncf techniques added
Actions

Also available in: Atom PDF