Why service configuration is included so late in the plenary object?

[jouvin]

I started to play with Aquilon services and found that the service information is included after the OS configuration has been done. Is there a good reason for that? I have the feeling that it should be included very early, right after the hardware configuration and before archetype/base. If I'm right, the service plenary templates have no dependencies on the OS. On the other side they can provide useful information for the OS configuration. For example, if you have a service dns that defines the appropriate DNS servers for each location, you may want to use this information to define the NAMESERVERS variable used by the template library OS templates to configure the DNS client. We may even think at using the Aquilon service information as a possible default value (when defined) for some services where we could agree on the standard name, removing the need for a few variables.

If you have such a use case, there is no possible workaround currently because you need know if the service is configured on the machine and which instance to use... Only placing the required service instance template in the object plenary can help here...

[jouvin]

Thinking more about this issue, I realized that the reason for the "late" inclusion of service templates is that they include both the service data template and a service configuration template which is empty by default but that the site can overload to include for example what is required to configure the service (including a feature for example). This would be broken if the service template was included early in the profile.

My proposal to support the use case I mentioned in the description without breaking the ability to add the service configuration in a site template would be to break the service-related includes in 2 different parts in the object plenary:

• Just after the hostdata:

"/system/services/name" = create("servicedata/name/instance/config");

• After the OS configuration (at the current place):

include "service/name/client/config";

The plenary template currently created service/xxx/lal/client/config would become useless and could be removed (no longer generated).

If this change is considered acceptable/useful but not desirable by default, it would be easier to bind it to an option (even if I share @ned21's view that this tend to make the code more complex to test/maintain and is better avoided if possible).

[ned21]

Adding more data to the host plenary is something we've talked about several times. In particular the personality information is something we would find useful much earlier in the compile. So if we are going to make a change like this I think it would be good to gather up all the changes to the host plenary into one release (albeit submitted and reviewed separately) and then sites only have to flush() once.

I think, in general, we also came to the conclusion that having all the data known to the database loaded before the start of template processing would make sense. Although in some cases plenaries are not valid until some prior templates are loaded as we saw with trying to load the TL before base.pan. So that may have influenced the decision to defer loading until after a certain amount of basic info about the archetype and OS was known.

There may also be performance and particularly locking considerations that may be the reason these changes have not yet been implemented, despite being very useful. The technical implications of this needs more discussion with the technical experts!

[jouvin]

I'm fine with the proposed approach. Nothing urgent, It would be good it you could ensure that the necessary people are involved on your side.

[ned21]

This should be looked at in conjunction with #89 which also modifies the host plenary.