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: