[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian images on Microsoft Azure cloud

- Should we require that the images only point to Debian repos, and/or
official mirrors: +1

- Require public review of images/plans: +Same as official site/mirrors,
tu use "Debian" name.

- to have a tasksel for "cloud server": +1

- default ssh user: +Leave at cloud provider criteria (can have own good
security policy).

I'm using this express-made address because personal addresses aren't
masked enough at lists.debian.org archives.

El 11/11/15 a les 21:18, Brian Gupta ha escrit:
> 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: