8:36 p.m.
On Aug 15, Reto Gantenbein wrote:
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.
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".
When the setup is done, exporting selected roles via automation to their
separate git repositories on GitHub and publishing on Ansible Galaxy should be
relatively easy. Not all DebOps roles would be exported, just something like
'debops.owncloud', 'debops.gitlab', 'debops.nginx' with their
dependencies.
The Galaxy users would be able to "taste" some of the DebOps environment, and
if they want, the can grab the whole thing.
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.
I don't think that the development model (one repository vs roles in separate
repositories) changes this. At the end of the day, DebOps is yet another huge
repository with hundreds of roles and playbooks, just laid out differently.
New users still feel overwhelmed with the project, and need to learn it before
trusting it. This is a documentation issue, and with a series of tutorials
with encreasing levels of complexity should be relatively easy to overcome.
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.
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.
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.
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...
The reason for this is that we are essentially duplicating the internal 'git'
repository mechanisms using Ansible Galaxy 'requirements.yml' file. How would
that change if everything is in a single repository? Any updates to a role are
in the 'master' branch of the main git repository, there's no need to track
role versions - in fact I'm not sure if role versioning would be needed at all
in this case, at least not as frequent. The main git repository would be
versioned as a whole, and exported DebOps roles on Ansible Galaxy could use
the same version numbers. Export could be easily done by a bot, the roles
published on Ansible Galaxy IMO don't need to be signed because a) they are
already signed in the main DebOps repository, and b) 'ansible-galaxy' command
downloads tarballs, not git repositories.
Keeping everything in one repository would allow for stable branches to be
maintained much more easily. Sysadmins could select one stable branch, say
'stable-2.1' and trust that DebOps suddenly won't destroy their production
environment with a rewritten role. Only backwards-compatible changes would be
backported if needed, and stable branches might just see bugfixes.
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.
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.
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.
All of the needed pieces are already available in DebOps. GitLab can be used
to host the git repository, manage pull requests and CI builds. Docker can be
used to manage the build environment via GitLab Runner. Privileged containers
would be a must, so without some way to review a pull request before
triggering a build I wouldn't setup a public instance just yet, but it should
be easy enough to deploy a private, fully fledged development environment. The
git repository could define multiple builds, separately for each DebOps role,
for their combinations, even using different OS distributions and releases
through Docker.
With one git repository there wouldn't be dozens of Changelogs to track, but
only 1 Changelog. Stable releases would be required to not do any changes that
break existing setups. Perhaps, with time, DebOps would also offer some way to
migrate between different releases. Also, with much smaller number of git
repositories to handle, detailed release notes are feasible to write.
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.
Tracking all these repositories correctly quickly becomes a nightmare, and you
are essentially reimplementing git to do this. Wouldn't it be better to use
the existing git mechanisms (branches, tags) properly?
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.
That's a good idea to implement in the tests. +1.
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.
GitHub has issues, milestones and projects which work wonderfully at
a repository level, but with multiple git repositories it becomes a mess where
you need to manually keep track of the issue/pr numbers in other repositories.
There's an organization-wide interface to list issues, pull requests and
create organizatin-wide projects (think Kanban board), but this interface is
reserved for members of the organization, and not public, which I don't like.
With one git repository this could be easily managed on GitHub, or perhaps
even project's own GitLab instance. TODO/ROADMAP file in the git repository is
also a possibility, which could be maintained in the same git commits that
implement a given feature or fix a given bug.
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).
Thanks for your thoughts! I would also like to see DebOps as an official
Debian package in a stable release. Unfortunately I don't think that is
possible with the current way the project is maintained, so I'm willing to
shake that up to see it happen.
Cheers,
Maciej