You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been on a multi-year mission to manage Salt data in the pillar in the best and most humane way possible and have landed with increasing conviction on pillarstack as the needed solution.
Pillarstack allows me to treat the world of configuration data as a collection of feature labels to be activated or deactivated, and in this way defining configuration feels more fun and rewarding, like playing a chord on a piano.
It's a wonderful abstraction, enabled by pillarstack.
As I've built onto, refined and come to increasingly rely on this capability I thought I should mention it to you, because it makes use of a profoundly powerful but undocumented feature of pillarstack - the ability to modify and read from the__stack__ variable using Jinja from within the pillarstack.cfg template.
I use a sub-hierarchy of the pillar, (designated into Question, Answer, Detail tiers), to control the inclusion of pillarstack files. As the sub-hierarchy is traversed information is preserved back into the pillar that is used to inform subsequent traversals. Also as a nicety, this traversal info is organized in the pillar as a log to make the logic "decisions" and outcomes easier to keep track of.
I feel this is exactly the right power in exactly the right place, so I'd like to see it enshrined and protected and celebrated. But just in case there was some need to alter it I'd ask that you keep the benefit and the use case I've described in mind.
Hi @bbinet ,
This is more of a use-case declaration.
I've been on a multi-year mission to manage Salt data in the pillar in the best and most humane way possible and have landed with increasing conviction on pillarstack as the needed solution.
Pillarstack allows me to treat the world of configuration data as a collection of feature labels to be activated or deactivated, and in this way defining configuration feels more fun and rewarding, like playing a chord on a piano.
It's a wonderful abstraction, enabled by pillarstack.
As I've built onto, refined and come to increasingly rely on this capability I thought I should mention it to you, because it makes use of a profoundly powerful but undocumented feature of pillarstack - the ability to modify and read from the
__stack__
variable using Jinja from within thepillarstack.cfg
template.https://github.com/genesis-matrix/gema-plr-core/blob/master/pillarstack.cfg
I use a sub-hierarchy of the pillar, (designated into Question, Answer, Detail tiers), to control the inclusion of pillarstack files. As the sub-hierarchy is traversed information is preserved back into the pillar that is used to inform subsequent traversals. Also as a nicety, this traversal info is organized in the pillar as a log to make the logic "decisions" and outcomes easier to keep track of.
I feel this is exactly the right power in exactly the right place, so I'd like to see it enshrined and protected and celebrated. But just in case there was some need to alter it I'd ask that you keep the benefit and the use case I've described in mind.
Cheers and many thanks for the project,
Nick
[1] https://github.com/genesis-matrix/gema-plr-core/blob/master/pillarstack.cfg
The text was updated successfully, but these errors were encountered: