11:23 p.m.
On cze 04, Jan Kowalsky wrote:
today, after installing debops via the debops.debops role on an
remote
ansible controller I realized that I was always confused about the
debops mono repo with rolling release vs the pip install command.
What I (hopefully) understood:
* when installing debops via pip everything is under
./local/lib/python3.7/dist-packages
Yes. The codebase included with the 'debops' Python package == the git tag ==
tagged DebOps Collection on Galaxy.
* after debops-update there will be an additional debops repo in
./local/share/debops/debops/
The latter is on git branch master - while the repo from pip is on the
release tag - but once I have an repo in local/share/debops it will have
precedence over the first according to file path order in .debops.cfg.
Right?
That's correct. However after some time I found out that this sometimes causes
problems with some functionality like a role, Ansible custom plugin, etc.
cannot be found in a first location - in that case Ansible tries the next
locations defined in the configuration file, which might be severly out of
data and the mismatch can cause problems after some time. So I think that the
next major update to DebOps scripts will be changed so that only one codebase
location can be used at a time, and it will be configuration-specific instead
of selected dynamically by the script.
What I did all the time working with debops, was ignoring the pip
installation and used git pull && git checkout <Release-Tag> to update
my debops to an stable release.
Now I realized that the debops.debops role always automatically cloned
the monorepo to /usr/local/share/debops/debops - in the master branch.
No I wondering:
* is it a good practice at all just to use git checkout inside the
monorepo - what I did all the years to get an specific release?
The roles and playbooks included in the 'debops' package weren't always
there,
so if you started doing it before IIRC v1.0.0 release you had to run
'debops-update' to get any content. But since now it is already included with
the Python package and the script knows how to get to it, that's not strictly
necessary - unless you want to use the 'master' branch.
* does the debops.debops role always lead to an debops version on
branch master or is there an possibility to configure an release?
Yes, at the moment the role always checks out the 'master' branch because
that's what the 'debops-update' script does. Looks like there's no support
for
changing the branch at the moment in the role. But that's a good idea to
implement.
And one last question: what purpose has the [debops_recursively] host
group?
Just a tongue-in-cheek... you are setting up DebOps using DebOps after all.
:-)
But I realize now that 'debops.debops' role can become confusing since we
already have 'debops.debops' Ansible Collection, which could have
'debops'
role which could then be called 'debops.debops.debops'... So I plan to rename
the role to 'controller' - seems that this would better indicate its purpose.
And as a bonus, the 'debops__' variable namespace could be free to use, maybe
for global variables or something else.
Cheers,
Maciej