Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.12.58: the broker should pass the archetype to the object template #88

Open
jouvin opened this issue May 27, 2018 · 3 comments
Open

Comments

@jouvin
Copy link
Contributor

jouvin commented May 27, 2018

Currently, the plenary object template generated by the broker doesn't contain anything about the Aquilon archetype used to build the host. This makes impossible for a generic (not archetype-based, e.g. feature or OS templates in the template library) template to include an archetype-specific configuration with something like:

include format('site/%s/feature_config', ARCHETYPE);

It would be good to have the broker adding this information in the generated template, either by defining a (final) variable ARCHETYPE or by adding it to the profile configuration as part of the host data. One advantage for using a variable is that it would be possible to define it before the initial LOADPATH with the following construct that will make the things more readable and avoid any risk of divergence:

final variable ARCHETYPE = 'linux';
variable LOADPATH = list(ARCHETYPE);

This issue is a spin off of the very long #86 discussion...

@jrha
Copy link
Member

jrha commented May 29, 2018

I would actually be very happy if it just did:

"/system/archetype/name" = "foo";

Our usage of the ARCHETYPE variable is largely legacy and could be easily replaced with value("/system/archetype/name").

@jrha
Copy link
Member

jrha commented May 29, 2018

In fact, I just checked and we no longer make use of ARCHETYPE, everything has already switched over.

@jouvin
Copy link
Contributor Author

jouvin commented May 29, 2018

I'm also happy if the broker assign the config path rather than a variable but I'd suggest my construct to make clear that loadpath is initialized with it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants