Allow for custom stacks - #75
Conversation
Stack templates will now move to a custom stacks repo.
Required by Ansible to use multiple defaults files.
Stack groups and stack names are now defined separately, allowing for custom stacks.
This setup keeps tracking the karo-compose role's defaults and templates directories.
Not all stacks will have their configuration present. This will now only set secrets 'when' the stack is 'enabled'. It's then safe to assume the user has defined the required secrets.
Using the combine filter is Ansible's recommended approach for merging multiple dictionaries.
This reverts commit d597a56. The use of dictionary data structures should be avoided.
The loop syntax is recommended over with_<lookup> by Ansible.
Used when editing the Ansible vault file.
Allows for adding and removing karo-custom repos.
Clearing symlinks also becomes easier, as it doesn't need to be recursive.
|
Tested with my existing server and the new hazzuk/karo-custom repo.
|
Ensures correct symlinks whenever the compose recipe is run.
|
The documentation has been brought up to date with these changes. And guides for both users, and karo-custom creators have been added. |
Applicable when users are creating a new empty karo-custom repo. But there is nothing to symlink.
|
@mosslocker following on from our walk-through of the docs, this PR is ready for review (including its related PRs). The key thing is the development experience of creating custom stacks. So before reviewing this, I'd suggest seeing if you can create a basic custom stack yourself from the info in the docs (can be something extremely simple). So long as the the foundational changes implemented here work well, then future adjustments can always be made. As always, thank you. |
mosslocker
left a comment
There was a problem hiding this comment.
Tested a custom stack on this branch w. Stack_Var included, works.
Description
This PR allows anyone the ability to create their own custom stacks, and to distribute them freely. Creating a fully modular system.
Changes
just custom, toaddorremovekaro-custom repos.Notes
Stacks now use a dictionary data structure.
composevariable, used in stack templates.Note, while this PR implements the use of dictionary variables. In general, this should likely be avoided for future features (unless there is a good reason to use this type of data structure). What a user declares in their inventory, and the defaults it overwrites can quickly become problematic when using dictionaries. Karo-compose has new functionality that specifically merges the two together for stack variables.
Users have to order their 'stack groups'. And each stack group will provide defaults for their internal ordering of stacks. This approach was implement as it's the ideal middle ground for control, versus the trade off of complexity (say if you were to require users to list and order every individual stack).
While there have been a large number of code changes to the karo-compose role's tasks. The general sequence for managing stacks has remained mostly the same.
Checklist