User story #9284
External Info Plugin framework
in various cases I've now used rudder-set-node-props.py to inject some info.
In my cases it has been very similar:
- system's usage class (prod/staging/...)
- system's applications (can be modeled one or many)
- enabling addons to be installed (i.e. have_docker=yes instead of app=docker)
I've done that with various providers and they usually got tagging support in different levels of quality.
In addition to tags there might also be infrastructure info available, i.e. which datacenter we're running it.
Enterprises will have CMDB's - to be honest that is quite the same info, just with much higher depth.
And the docker crowd tries to have everything in Consul, and still is on an uphill battle to give that higher data quality than the ubiquitous excel system documentation.
(lack of constraints in the data model)
Ah, yes, and the excel users.
I think something for the future is to think about a common layer to provide
- multi-node updates (atomic, so you don't have races)
idk what else might be coming.
right now we're all still working to have better scripts to inject the properties and build rules of them.
this is to raise attention that there might be a need of a stronger interface in the future.
(time for me to test the csv export contrib script, too)
Updated by François ARMAND almost 4 years ago
I'm not sure about what you mean by mapping and constraint - is it something like a schema support on JSON node properties, à la AVRO schema, or JSON schema (http://json-schema.org/examples.html) ?
For the multi-node commit, I think what you really want is the possibility to have complexe change request done by the API, one such change request being able to touch any number of directives / rules / groups - and node properties. Or perhaps you don't care how it is implemented behind the scene and you just want to be able to change properties on several node in one go :))