7:32 p.m.
Hi everybody
Here a few thoughts from me about this issue. I was reading this
article too and indeed, it has some interesting thoughts but for most
issues mentioned there, I fail to see the relation to DebOps.
First of all I'm very much in favor of keeping the existing
repositories per Ansible role as long as this is required for the roles
to appear on Ansible Galaxy. First of all DebOps is about Ansible roles
and all of us are putting a lot of effort into writing sophisticated
roles, so in my opinion it's a big loss for all of us with they won't
be published on Galaxy anymore. Not only does it help to access roles
independently of DebOps, but it also acts as advertisement for DebOps
and helps other role authors to learn how certain issues can be solved.
There are many other advantages as already nicely summarized by drybjed
in the initial mail, I don't have much to add here. Maybe one point
that I would like to mention that for new users/contributors it might
be much easier to grasp the idea of Ansible roles and DebOps if they
can easily read and run an individual role instead of a huge repository
with hundreds of roles and playbooks. At least I got this impression
when trying to dig into openshift-ansible [1] which is meant to setup a
OpenShift container PAAS and also consists of dozens of Ansible roles
with lots of possibilities and interpendencies.
Now to the pain points:
The major issue that I see with DebOps is stability and consistency.
These are both points that were already mentioned where a mega-
repository would be somehow beneficial. But in my pov a solution to
this would not happen by itself it needs a lot of work in both cases.
Stability:
DebOps definitely should have a way to "freeze" and properly test and
package a state of the Ansible roles which can consumed easily by
sysadmins who prefer to focus on application and architectural issues
and not bootstrap and configuration management issues. The current
distribution model of DebOps with updating the roles through git and
the constant rate of changes and redesigns of roles doesn't help to
build confidence. DebOps should help to make things easier for its
users not more complicated.
For this to improve there must be a way to easily package DebOps as
Debian package(s). As no one invested much time into this obviously is
an issue. There needs to be a script which will generate a bunch of
source archives out of a snapshot of the involved repositories. I would
imagine to have a bunch of bundles such as 'debops-tools', 'debops-
roles-base', 'debops-roles-webapps', 'debops-roles-virtualization'
and
so on which could be installed and released loosely. There should be a
way to define in a project if it should run against the stable roles or
(for developers) use the git versions as today.
These packages should then be able to pass the setup of complicated
environments (remember: datacenter in a box). As mentioned before
Travis-CI won't help here much, as such tests are much too expensive to
run there. This means we should definitely have a beefy CI box to test
DebOps "releases". Upgrades of such releases must be easy not ask the
user to check and understand dozens of CHANGELOG files and then analyze
its configuration trying to figure out what he has to change where.
In a distributed world this CI machine would then also be responsible
for branching and tagging the individual repositories appropriately as
it is required to create releases and bugfix channels.
Consistency:
There are already a nice bunch of policies and guides available for
DebOps but they have to be read and understood and there is no
automation available which checks and enforces those. With ansible-lint
[2] and ansible-review [3] there are already some tools available which
could be leveraged to improve and maintain consistency in this large
number of roles.
Manageability:
I didn't mention this as a major pain point as I'm not much involved
into managing DebOps as a whole. drybjed definitely also mentioned some
valid points to this topic like project wide changes or reviews. Not
sure how often this really happens and if this couldn't be also tracked
by something like "release milestones" which must be implemented before
a new "release" will be made.
These were some of my thoughts. If some effort regarding packaging
should be made, I'm definitely willing to help as I'd love to see a
DebOps package in Debian (or at least on my servers).
Cheers,
ganto
[1]: https://github.com/openshift/openshift-ansible
[2]: https://github.com/willthames/ansible-lint
[3]: https://github.com/willthames/ansible-review