Re: Debian images on Microsoft Azure cloud
On Wed, Nov 11, 2015 at 9:53 AM, Steve McIntyre <steve@einval.com> wrote:
> On Tue, Nov 10, 2015 at 07:34:04PM +0000, Martin Zobel-Helas wrote:
>>Hi all,
>
> Hey Martin,
>
>>as announced during DebConf15 and in <55D03D49.1030608@debian.org> and
>><CABHrTiLStCxKURwMQ0gvUdfz3dDQHdwr1UGoYosJuFhz1-E-=w@mail.gmail.com>
>>Microsoft contracted credativ to build and maintain Debian images for
>>their public cloud infrastructure "Microsoft Azure". Microsoft intends
>>to endorse Debian and provide support for Debian Jessie and Wheezy
>>images.
>>
>>In the past months credativ setup infrastructure to automatically build
>>and publish Debian Jessie and Wheezy images. The build process consists
>>of a published set of tools that automate everything from building to
>>uploading of images.[1] It is conducted using a public accessible
>>Jenkins instance.[2]
>>
>>The image build process uses a fork of the current OpenStack image build
>>script, which we intend to merge back to upstream. This script is
>>included in our tool set. There are two modifications to a standard
>>Debian Jessie/Wheezy image:
>>- isc-dhcp is imported from -proposed-updates to include a bugfix.[3]
>>- waagent in included in version 2.0 on request of Microsoft, which
>> can't be provided via backports at the moment.[4] Microsoft
>> works on getting version 2.1 ready for production, this version is
>> currently in Stretch and can be provided via backports at least for
>> Jessie.
>>Additionaly the wheezy image uses the kernel 3.16, initramfs-tools and
>>init-system-helpers from backports.
>
> OK, they all sound reasonable.
>
>>Microsoft itself conducts CI tests of selected images using a published
>>set of tools.[5] Results of this tests are not public.
>>
>>Microsoft would like to use the Debian name and logo to promote those
>>Debian images in the Azure Marketplace.[6] credativ will maintain and
>>enhance those Debian images and Debian developers at credativ will
>>accompany this process.
>
> My only concern is that I'd be happier if the builds were created and
> hosted on Debian project machines, like our existing official
> builds. I've been discussing that with other people for other types of
> build. How awkward/difficult would that be?
>
> --
> Steve McIntyre, Cambridge, UK. steve@einval.com
> Is there anybody out there?
(Note: Although some of you may know that I am a member of the Debian
TM team, I am raising the following issues as a long-time participant in
the debian-cloud group/mailing-list. I also apologize upfront for the length
of this email, and for any inevitable omissions.)
At this point I'm trying to understand what criteria people are using to
weigh in support, as it's unclear.
When the AWS (Amazon Web Services) EC2 and the GCE (Google
Compute Engine) teams brought their plans to debian-cloud for review,
many criteria were raised and used in the evaluation. (Perhaps people
are subconsciously using these same criteria, but it is not obvious.)
Sadly, it seems we didn't capture those criteria in some sort of policy doc,
but I think we can hash it out once more, and come up with a list. Well,
actually we started to capture it, but it's clearly incomplete. [1]
Having this list will be incredibly useful to people trying to make official
images for additional public IaaS clouds. I'm taking a first pass at reviewing
the AWS and GCE discussions, and am attempting to capture points of
consensus. (Please feel free to correct, or fill in missing criteria,
as there were a lot of emails over a multiyear period, and I'm sure I
missed things.)
1) the image includes only software available in Debian [2]
2) the image generation process is controlled solely by Debian [2]
3) the image is generated using tools available in Debian, or maintained [2]
by Debian
4) Only DFSG-compliant Software in the image. Only main enabled, with
perhaps a temporary exception for backports [3], for specific enablement
software
6) the images most provide a user experience (in terms of default
choice of packages, or of default configuration) identical to other
means of installing Debian. Differences must be documented and
justified. [4]
7) Debian kernel [5]
8) Built using Debian infrastructure [6] (I think this should be modified to
have a caveat, "to as much an extent as possible")
There are other considerations as well that I'm not sure if we've addressed
before.
1) Should we require that the images only point to Debian repos, and/or official
mirrors? If not, what are the requirements here?
2) Require public review of images/plans (where? I think debian-cloud
and debian-cd are the right places, but there may be others)
3) How to deal with remediation of non-compliant images? There are two
issues here:
a) if we discover that one of the requirements isn't being met, we
need to have a process for complience to be achieved in a reasonable
time period. Depending on what the issue is the time period can vary. I
could see some being able to be addressed for the next stable release,
and some requiring immediate remediation.
b) An image could be largely compliant, but for reasons of timing can't be
made compliant until the next Debian stable release. I believe it's in
Debian's interest to find a way to make time-limited exceptions so
people don't have to wait up to two years to ship an image. e.g. -
Allowing a package from backports rather than main. Of course the
expectation should be that the exception is for a bug that will be fixed
by a certain date.
4) Documentation? Is it enough to just put it in wiki.d.o, in the cloud section?
In addition, as a user of public clouds, and a Debian user, I have the following
expectations, that are likely representative of a larger group of users..
1) Debian images that exist for the various public clouds, should
contain the same set of core Debian packages as other public cloud images.
IE: As much as possible I'd want to see the same (or very similar) Debian
experience across all public clouds. Perhaps the answer is to have a tasksel
for "cloud server"? [8]
2) The images support cloud-init when the cloud vendor supports custom
metadata, to allow the images to run custom configuration about
instantiation. (This is essential for many people to use of these images in
any significant way.)
3) What about the default ssh user, for those clouds where this isn't configured
at instantiation? Shall we standardize on debian-user?
Other questions:
1) bootstrap-vz is used to build the AWS and GCE images. bootstrap-vz has also
had support for Azure for at least two years. Is there a reason
the same tool wasn't used?
[1] - https://wiki.debian.org/Teams/DPL/OfficialImages
[2]- https://lists.debian.org/debian-cloud/2013/04/msg00085.html
[3] - https://lists.debian.org/debian-cloud/2013/05/msg00011.html
[4] - https://lists.debian.org/debian-cloud/2013/05/msg00058.html
[5] - https://lists.debian.org/debian-cloud/2013/04/msg00068.html
[6] - https://lists.debian.org/debian-cloud/2015/08/msg00015.html
[7] - https://wiki.debian.org/tasksel
Reply to: