Rudder

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 ?

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

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.

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?

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.

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)*

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.

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