Ticket #701 (closed enhancement: wontfix)

Opened 14 years ago

Last modified 11 years ago

Include bcfg2-repo-validate functionality in bcfg2-server

Reported by: mccallis Owned by:
Priority: minor Milestone: Bcfg2 1.2.1 Release (Bugfix)
Component: bcfg2-server Version: 1.0
Keywords: Cc: [email protected]


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.



Change History

comment:1 Changed 14 years ago by solj

  • Milestone set to Bcfg2 1.0 Release

comment:2 Changed 13 years ago by desai

  • Status changed from new to accepted
  • Milestone changed from Bcfg2 1.0.0 Release to Bcfg2 1.0.1 Release

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

comment:3 Changed 13 years ago by solj

  • Milestone changed from Bcfg2 1.0.1 Release to Bcfg2 1.1.0 Release

comment:4 Changed 13 years ago by Remi Broemeling <[email protected]…>

+1 vote for implementation :)

comment:5 Changed 13 years ago by solj

  • Milestone changed from Bcfg2 1.1.0 Release to Bcfg2 1.2.0 Release

comment:6 Changed 12 years ago by solj

  • Milestone changed from Bcfg2 1.2.0 Release to Bcfg2 1.2.1 Release (Bugfix)

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.

comment:7 Changed 11 years ago by

  • Owner changed from desai to
  • Status changed from accepted to assigned

comment:8 Changed 11 years ago by

  • Status changed from assigned to closed
  • Resolution set to wontfix

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.

WARNING! You need to establish a session before you can create or edit tickets. Otherwise the ticket will get treated as spam.


Add a comment

Modify Ticket

Change Properties
<Author field>
as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.