- 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 <st...@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.1030...@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. >> st...@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 >