Relaxed feature template checks in bind feature and manage commands

quattor / aquilon

Configuration Management Database (3rd Generation)

www.quattor.org

Apache License 2.0

14 stars 19 forks source link

Relaxed feature template checks in bind feature and manage commands #112

Open jouvin opened 6 years ago

jouvin commented 6 years ago

This PR addresses issue #111 by:

Looking for feature templates in the root directory of the domain Git repo, in addition to the archetype directory.
Enabling a relaxed feature template check when config option relaxed_feature_template_check is true (false by default) where a warning is displayed if the template existence is assessed rather than raising an exception. This allows to support direct use of template library features.

Not done yet:

Removed check in aq manage if --skip_auto_complle is not present: not clear what the added value would be as it will not help much is you don't have relaxed_feature_template_check=True and will only remove the warning if you have it.
Option to enforce that only one feature template must exist in the domain Git repo, whatever the location. Waiting for feedback on whether it is needed or not.

Successfully tested at LAL.

ned21 commented 6 years ago

As stated in the issue this fixes, I think it's a bad idea to break the name spacing in this way. If the patch were to be accepted, all new code paths would need unit test coverage.

jouvin commented 6 years ago

@ned21 I don't really understand your comment here. I don't think this PR breaks name spacing in any way. Name spacing in Pan is relative to the loadpath and this is the real power of it. This has been the important feature (introduced around panc v6 or v7, not a feature from the origin) that enabled the template library concept, making it feasible. So this PR just allows to use the full power of Pan name spacing with Aquilon, something that was somewhat restricted by the initial implementation. But as said in the issue, it has a price (like the current implement has the price of restricting the power of name space + loadpath combination), this is why I propose to have it a configuration option that allows each site to makes its own decision about the model which is most adapted for it.

jrha commented 6 years ago

I really don't like the idea of allowing features at the root level, users (and tooling) expect to see nothing but archetypes there, I do however like the idea of sharing features between archetypes. See my comment on #111 about what we did to allow sharing at RAL.

jouvin commented 5 years ago

After discussion, decision to implement both features with separate options, using the RAL approach of a directory dedicated to shared features.