Include bcfg2-repo-validate functionality in bcfg2-server

[mccallis]

This is an enhancement request and probably a subjective opinion. It seems like bcfg2-repo-validate performs useful error-checking and can flag problems in the repository that will prevent the bcfg2-server from functioning as the user intends. It also seems to execute pretty quickly for me, taking less than a second of real clock time. Why doesn't bcfg2-server validate every repository element before using it, whether at start-up or when an element is modified while the server is running?

Here is an example of where such functionality would have been useful to me. The Service element has an attribute type that became required in r5096. Both I and the person who logged #551 seem to have been tripped up by a previously valid repository no longer validating with the new version of bcfg2. It took a fair amount of head-scratching on my part to figure out that when bcfg2 complained that my service entry "was not handled by any tool", it was due to a missing XML attribute. On the other hand, bcfg2-repo-validate is spot on, giving me a clear error message, source file, and line number.

I appreciate that the right thing to do with the current version of the tools is to run bcfg2-repo-validate more frequently (i.e., after making almost any change to the repository), but that seems like an extra manual burden to place on a system administrator when bcfg2-server could do this at relatively low resource cost.

Mike

[desai]

This is a good idea, but it will have to wait for 1.0.1

[Remi Broemeling <…>]

+1 vote for implementation :)

[solj]

I think this could be relatively easily doable with the new bcfg2-lint rewrite. It probably won't be done, however, until 1.2.1.

[https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc]

Thinking about this more, I don't think we can reasonably implement this. Bcfg2 has no concept of a "change set" -- e.g., the set of stuff that you check into your VCS. The FAM just reports individual changes, so an update to the Bcfg2 repo could be a set of 1 or a dozen or a hundred individual changes, and we surely don't want to run bcfg2-lint a hundred times.

We might be able to do something crazy like running bcfg2-lint on every change, and then suppressing it for 5 minutes (e.g.), but really the right thing is to run bcfg2-lint in a precommit hook in your VCS.

Even adding bcfg2-lint functionality at server startup time isn't exactly trivial; bcfg2-lint requires a config file, by default /etc/bcfg2-lint.conf, so that would have to be specified to the server somehow. Since bcfg2-lint also depends on the path to the schema files, that would need to be added as well, so we'd be adding two options to the config file without which the server would refuse to start (at least, on non-default installs).

Adding the functionality just on server startup is pretty weak anyway, so I'd really recommend just adding bcfg2-lint to your precommit hook. It adds the right stuff in the right place without requiring any major config file changes, and it works on every commit, not just server startup.