Configuration Validator: modularity

[malex984]

@elondaits commented on the internals of hilbert-cli-config.py:

In my experience (and this is not a hard rule, just a comment on errors I made in my past) it's better if individual components consume "their part" of the cfg on their own, and validate it on their own. The config loader simply validates the general syntax (what the YAML parser is doing now). That way you can modularly extend the system and each module/class "knows" what the correct options and values are. If you have a single "config validator" class then that class holds internal knowledge of every class in the system, which breaks modularity.

[malex984]

@malex984's reply :

each Validator class only knows about its structure (which may depend on the format version). Tool can extend by adding new Validator classes and new rules to existing one (for later format versions).

[malex984]

@elondaits reply:

For instance, your StationPowerOnMethod class is instantiated by Station... so Station "knows" StationPowerOnMethod...so it's coupled. Following the dependency tree from the top down you get to every class.

The alternative that usually works better for me is for every component to handle its own config. Analogous to how the Windows registry is used by different applications and they are free to use whatever keys they want (either their own or any others they have access to). The config is a centralized store of operational parameters, but each component knows what information it needs from it.

[malex984]

IMO poweron_settings: StationPowerOnMethod is an integral part of a Station, which was separated only to make a clear structure due to multiple types (e.g. it may need Station's address).

@elondaits Which parts of our current configuration you would treat that way? Do you know any open example for such a modular design?

[elondaits]

In complex applications I tried the approach where the top level component (in the object instantiation tree) read the CFG and then passed on to its children the parts they needed (and those parts passed relevant cfg to lower levels, etc.) This creates messy code where encapsulation and modularity are broken.

Instead I had better luck in the approach where the cfg is loaded, parsed, and either kept as a global object or passed to new objects that require it always as a full thing. Then each object knows which parts of the cfg to read on its own... and don't care about the rest.

In the case above, even if the concept of "power on settings" is essential to the station, that doesn't mean the station has to know anything about what settings are needed for that. Does the component in charge of powering on stations require a MAC? An IP? A URL? A timeout value? Some other parameter? The station shouldn't know or care, because that's relative to the internals of the module doing the power on (which could even have special settings for debugging).

Validating the whole cfg is a harder problem with a modular design, because no module knows the full description. To this, I have three things to say:

• Most programs DON'T validate the full cfg. If it's syntactically valid they don't care about its "semantic integrity". Just like a compiler doesn't care if you write a program with a runtime error. You can misconfigure Apache, mySQL, sendmail, and any other server system and won't get errors or warnings until it attempts to do something that's not possible. I'm not saying we shouldn't do it, but it shouldn't be our priority above our more basic requirements (having a basic working system). I would push back this as a "nice to have" feature for later... which could very well be before the system goes into production.
• Another possibility is validating with a YAML schema. A schema is a declarative description of the valid contents of the file. It breaks modularity but it's very easy to change and doesn't require code. The problem is the schema would validate valid/invalid keys and their types... not more complex constraints / semantics. But it's a very low cost partial solution.
• The way to validate the full cfg in a modular fashion is that each component/module that will consume the cfg registers itself as a "cfg validator" and passes along the name of the class that it will use to validate its portion of the cfg. Then when you want to validate the cfg you instantiate each registered class and call a validation function passing the cfg as argument. You can keep track of which parts of the cfg where validated and then produce a warning if there was a branch that wasn't validated by any validator. This approach uses "dependency injection" which is a popular pattern to modularize and decouple the higher level classes in modern OOP.

[malex984]

@porst17 @elondaits I am planning to create a json schema for validation of Hilbert YAML Configuration following Docker-Compose approach: https://github.com/docker/compose/tree/master/compose/config

IMO this has low priority ATM since it is an improvement/re-implementation of what is already available. Ok?

[elondaits]

Why JSON and not a YAML schema? Kwalify and Rx (two of the more popular schema validation libraries for YAML) support YAML schemas.

But I agree it should be low priority.

[malex984]

@elondaits I have no real preferences yet (just stumbled upon several advises about json schema validation...)

ps: here are some suggestions: http://stackoverflow.com/questions/3262569/validating-a-yaml-document-in-python

[elondaits]

I see the second answer suggesting using a JSON schema validator based on the fact that they're "similar" so you can validate "a sizeable subset of YAML", but there are enough YAML schema validators and most of the ones I've seen do both.

[malex984]

@porst17 no such modular Validator. Can we postpone this for some later project?