jay7x
commented
1 year ago My point is to be able to run bolt plan run control_repo::apply to apply on every agent with its correct role.. i.e. you don't need to keep the agent -> role mapping in your head. This allows to do "hosts" unit testing as well (see spec/hosts for an example).
Second point is that big infras with >100 servers are out of this repo scope.. I'd say one shouldn't use push model for such big infra.
Third point is to keep the repo structure as close to an usual control repo as possible. I.e. you should be able to drop this repo into an environment directory and your puppet server should be able to use it. Though this point is not a hard requirement here.
Though I understand that writing a file per node is not the activity ppl usually like to do.. My first idea was to use bolt inventory vars for classification. I realized quickly that it doesn't work for dynamic inventories (like terraform or lima or any cloud). While agent hostnames can be static their transport settings will change frequently.. so hiera was easiest and familiar enough choice for everyone.
If you still would like to pass a role via CLI I'd say easiest way is to write another plan next to apply.pp which will read the role parameter and include it. You won't be able to use bolt apply (only bolt plan run control_repo::<new_plan>) then though..
I saw that you talked about a future with other ways of classifying. Would it be possible to just use a CLI option like
--rolesin the bolt command? That would prevent haven dozens upon dozens of files each specifying a different role.