Accepting cloud enablement package updates into Stable
Hi,
tl;dr: We'd likt to be able to update key cloud packages in Stable, as
we consider them being just like Kernel drivers for the cloud.
Longer version:
During a discussion in the debian-cd and debian-cloud list (cross-posts
discussion), we all agreed that we would really like to have a more
liberal approach to updating cloud high-profile packages (like
cloud-init) in Stable. This message is an intend to discuss it outside
of the closed sphere of the cloud people, with the more broad community.
So, let me start and explain what the problem is.
As you know, we don't allow changes to happen in Stable, as they may be
disruptive and could cause unexpected issues. Though we do allow new
kernel drivers to enter after Stable is released, because we want to be
able to support more, and newer, hardware.
It is my view (and probably the one of many others working on the cloud)
that key software like cloud-init are kinds of drivers for the cloud,
and that it is critical that they can be updated to support newer clouds.
If we don't allow such updates in stable, then there are a few
alternatives which can be used:
* We can upload updates to stable-backports for example. But this means
that, to keep packages updated, we should also add stable-backports to
the image sources.list, which may be disruptive and not desirable. This
also taints the cloud image as not being completely Debian Stable, which
we all would prefer to avoid.
* Another alternative is to use specific packages outside of Debian.
Then the image becomes effectively a derivative of Debian, which is even
worse than providing things through stable-backports.
Also, we'd like to be able to call as many cloud images we support as
"Debian Stable official cloud image", meaning that the images can't be
tainted with packages from jessie-backports or Sid (and even less
non-official Debian repos).
We're currently releasing a cloud image for OpenStack, updated on each
point release (which btw, could work on many other clouds if we take
care of it properly). Meaning we're exposing this as a final artifact
we're publishing, just like installer ISO. And it's state is currently
not as good as we wish it could be.
So, basically, any option besides updating Stable is not satisfying.
Of course, we'd like to keep changes as minimal as possible. Though even
doing that, it is very difficult to convince the release team. See for
example this bug entry:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789214
tl;dr: We're asking to add some .service files to cloud-init in stable,
because the way systemd schedules things with initv scripts, the order
is just wrong, and things may break. On a vanilla OpenStack image,
that's fine, but as soon as you add new daemons and services, it starts
to show.
So the only way to fix things is to get the .service files added to
Jessie. The issue has been pending since the 19th of June, with still no
decision from the release team.
And this is a very trivial fix that we've been proposing. I also do
understand that the reason why we don't have a release team decision on
this bug is probably because they are very busy, and that it's not very
easy to understand what the problem is. Never the less, we'd still like
to have a resolution for this problem.
Also, we'd like to be able to ask for more, like adding support for
clouds which we don't support yet (for example: Azure). This would mean
much bigger patches to cloud-init, and even probably upgrades to a
higher version of it.
Of course, before asking for such changes, we would do extensive testing
on all supported platforms. Having a set of automated tests is also
currently discussed at debian-cloud@l.d.o. It is my strong opinion that
we should define this required set of tests (meaning we'd define which
platform we want to strongly support), and not allow any update if these
tests didn't pass.
Your thoughts everyone?
Cheers,
Thomas Goirand (zigo)
Reply to: