7:56 a.m.
On Tue, 2017-08-15 at 20:36 +0200, Maciej Delmanowski wrote:
I'm not saying that all of the DebOps roles should be wiped from
Ansible
Galaxy completely. The current project model can be summarized as
"create
roles separately and then combine them in a bundle". What I'm
proposing to do
is reverse that into something like "create a consistent bundle of
roles and
expose the interesting ones on Ansible Galaxy".
What's the difference between a DebOps Ansible role and an Ansible
role. Except a few DebOps-specific modules it's mainly conventions.
That said, I see the development approach of DebOps more like the
nowadays often discussed microservice architecture. There are
individual pieces each one solving a specific task and respecting some
conventions, but each can be developed separately even by different
teams. The same approach is also written down in the DebOps policy
about organizational structure. Changing this to a centralized approach
would in my opinion:
- Lower the chance that 3rd-party developers would want to "donate"
their roles to DebOps as this would reduce their control and they would
need to hope that their role is an "interesting" one or they develop
and keep it separately to control what is on Galaxy.
- The role maintainer model has to be given up (at least privilege
wise). Either one is a main developer of DebOps and has access to
everything or one has no rights.
- It's harder to follow development and see issues of individual roles
as everything will be mixed together.
In the curren state this "freeze" would need to be handled
in the
'debops-playbooks' repository. Since the roles in separate git
repositories,
only mechanism that is valid to use to freeze on specific role
versions is
Ansible Galaxy 'requirements.yml' file, which would specify all of
the roles
and the desired versions.
In the current state yes. However, I would understand a freeze with the
current layout to be a tarball of a repository state with a version and
each repository tagged with this version. For stabilizing, there can be
a branch of this version where bug fixes can be applied. Obviously the
requirements.yml file can follow whatever versions it wants to.
Let's say that DebOps offers two "stable" branches, 1.x
and 2.x, each
one with
a frozen set of roles. there's also separate 'master' branch which
gets
updated before being frozen. Now, a 'debops.nginx' role has some
updates and
a new version is released, now that version needs to be updated in
the
'debops-playbooks' 'master' branch. And then 'debops.sshd', and
'debops.gitlab', etc., etc. Each release of a role requires a
parallel update
in 'debops-playbooks'. Note that right now an update in the playbook
repository is needed only when a new role is added, or a playbook of
an
existing role is updated; otherwise 'debops-playbooks' is not changed
all that
much.
There is nothing like individual releases of roles. Even it might
contradict a bit to my distributed approach that I defended above, but
a release is primarily a DebOps release. It still can be a all or
nothing approach even with multiple repositories.
Without changing the development model of the project and
implementing
"freezes" like the above, that would put even more pressure on the
project
maintainers and add even more work. Can this be automated? Not
without
automating commit signing...
Maybe a "simple" script to do the relevant part which is executed by
the project leader would be sufficient? Close the CHANGES.rst and
update the requirements.yml?
There was an attempt to do this by a Debian Developer a while ago (I
linked
the relevant Debian bugs in my initial post). Unfortunately this fell
apart
because of how the documentation is currently managed in DebOps via
git
submodules - this resulted in lots of duplicated role code in the
'debops-doc' package which couldn't be passed through Debian lintian.
Keeping
everything in one repository wouldn't have that issue and a 'debian/'
directory with build instructions could be included as well.
Yes, I'm aware of this and I can feel with him as I'm doing a lot of
packaging work too. I feel the main issue was, that he tried to build
the package out of git directly which is a pain because of the
distributed repositories. I think a lot could be simplified if there is
a release tarball as mentioned above which can be used as basis.
As you can see, I'm a user of individual roles and a contributor of
individual roles (mostly in contrib). The entire DebOps might become
interesting to me when there is something like a stable release that is
well tested. I'm happy to support you in trying to achieve this but I
only have a few hours per week that I can spend on this. So for the
time being, I use the roles separately in the same way as other Ansible
roles.
At the end you are the project leader and DebOps is where it is today
because of all your hard work and your decisions. Just keep going...
Cheers, ganto