To cross that bridge is good, being aware all the time about what's exactly the thing. In the meanwhile, a "derivative" image can be named as "Debian based".
"Official mirrors" shouldn't contain differences to debian.org repositories. Otherwise they should be named "Debian based" too. __________ I'm using this express-made address because personal addresses aren't masked enough at lists.debian.org archives. El 20/11/15 a les 04:42, Brian Gupta ha escrit: > On Wed, Nov 18, 2015 at 8:12 AM, Martin Zobel-Helas > <martin.zobel-he...@credativ.de> wrote: >> Hi, >> >> On Wed Nov 11, 2015 at 15:18:51 -0500, Brian Gupta wrote: >>> (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.) >> >> I see some conflict of interest here, but i will answer the technical >> questions. > > Responding here as an individual member of the TM team. (Not on behalf of the > TM team, as I've been swamped and we haven't had a chance to discuss). > > While I'm not sure if I have a "conflict" of interest, I will admit that I am > hoping to kill more than one bird with a single stone. First, I'd like to > help you resolve your TM request, in a way that is agreeable to the Debian > Project and your team. > > Second, as there is a growing consensus developing for Debian to be publishing > official cloud images, and at least one of the teams involved in publishing > Debian images has expressed an interest in building/blessing cloud images, > I'm hoping that this discussion promotes the development of a more fleshed out > set of standards and policies related to Debian cloud images. This will > hopefully make everyone's lives easier in the future. > > I'll also add that it's not the TM team's role to privately set technical > policy, which is why we advocated to have this discussion in public > with the appropriate technical teams. > >> First of all, i want to stress out, that i didn't request the trademark for >> the >> name "Official Debian images on Microsoft Azure cloud". I am happy to help >> here >> that we, at some future point, might reach that status, but as per discussion >> (where never a final decission was made!) during DebConf15 we mostly agreed >> that we should be careful what we call "Official Debian". Therefor we would >> like to use "Debian Jessie/Debian Wheezy build for Microsoft Azure". > > So my position here, which is being shaped by ongoing discussions, is that you > are asking the Debian TM team for blessing or sanctioning to call a product > you > built, "Debian". That's about as "legally official" a blessing as one can get. > > Going forward, if one of our teams (say debian-cd) decided they wanted to also > build Azure images, do you feel that there should be two separate sets of > images, built by two separate sets of DDs? Which is official, if they both > received the blessing of the project? From a user's point of view this could > lead to great confusion, and would make the job of the TM team quite a bit > harder, especially if there were disagreements about how the images are > built. > > At this point in time, the only "non-official" blessing I would prefer the TM > team be involved in would be perhaps for temporary transitional images > that may not quite be ready for official status, but the DDs are committed > to resolving any issues, the issues aren't considered showstoppers, and the > technical teams involved support that plan. (Definitely open to feedback here, > and this may change over time as we evolve our policies.) > >>> 1) the image includes only software available in Debian [2] >> >> Check. Our image only includes software available in Debian, except waagent. >> waagent is available in Debian itself, but not the version we currently need >> for the image, see my initial mail for more information. >> >>> 2) the image generation process is controlled solely by Debian [2] >> >> Check. Only DD have write access to the Jenkins instance used to generate >> images and control the scripts used by the process. Apart from the usual >> vendor >> operation staff, of cause. >> >>> 3) the image is generated using tools available in Debian, or maintained [2] >>> by Debian >> >> Check. The tools are maintained by DD. >> >>> 4) Only DFSG-compliant Software in the image. Only main enabled, with >>> perhaps a temporary exception for backports [3], for specific enablement >>> software >> >> Check. >> >>> 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] >> >> Check. >> >>> 7) Debian kernel [5] >> >> Check. For Wheezy we need to use the kernel from backports. >> >>> 8) Built using Debian infrastructure [6] (I think this should be modified to >>> have a caveat, "to as much an extent as possible") >> >> In general I support this idea. But for the current process of building those >> images is based on a contract our company have with Microsoft. This would >> violated the DMUP that clearly says: "Don't use Debian Facilities for private >> financial gain or for commercial purposes, including consultancy or any other >> work outside the scope of official duties or functions for the time being, >> without specific authorization to do so." The process of modifing the DMUP >> should be discussed elsewhere. The publishing of images requires login >> credentials to the vendors publishing API. In most cases those credentials >> are >> in some way linked to credit card data.... Do I really need to say more? >> Currently building images for whatever vendor requires root permissions on >> debian.org boxes. While I have them, using them would be an abuse of my DSA >> position. Also we eat our own dogfood and use Azure images to build Azure >> images. > > It's my opinion that if the relevant teams believe that these tasks > should be run on Debian hardware, then we will support that decision. > Many people are paid to "work on Debian" so I'm not sure I understand > the issue? It's also likely that the work could fall under "official duties" > if they were blessed by the appropriate team(s), which is a likely outcome > of this discusison. > >>> 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? >> >> That idea is complete nonsense. a) We have several layers of checksums and >> cryptographical signatures on the Debian archive and apt requiring the >> correct >> archive signing keys, so apt would start to complain immediately. What we >> could >> do as requirement is that every vendor needs to list all imported keys from >> "apt-key list" in the published build log of the image. b) In most cases >> vendors offering Debian run mirrors internally, which are available with much >> better connection than our official ones. Those can be verified by apt (see >> (a)). Cloud vendors usually bill for external traffic, sometimes only one >> direction, sometimes both. So your idea would result in our users needing to >> pay even more money to the cloud vendors. While the cloud vendors might >> support >> your idea, I personaly (without any hat on) think it is a very bad idea. > > To be clear I am NOT proposing that a Debian mirror can't exist within > a public cloud. > > Perhaps I have a misunderstanding of how official mirrors work, (Or even may > be > mistaken in my believe that there are such things as "official mirrors"?) > > My view would be that images should point to "official repos/mirrors", > and if an image building team wanted to point to different repos, they > would get the blessing of the team responsible for overseeing our mirror > network. (DSA?). > > IE: Why can't these mirrors become "official mirrors", for use with a > specific public cloud, if they follow Debian's rules, and don't have > random arbitrary packages in them? > >>> 2) Require public review of images/plans (where? I think debian-cloud >>> and debian-cd are the right places, but there may be others) >> >> I like the idea in general. Will we be able to support the review process for >> all different vendors? Will we be able to verify images / review images for >> cloud systems that are not that widely used as Azure, AWS, GCE or Openstack? > > I don't think there is a formal process, but there has been countless > discussions shaping decisions made for AWS and GCE on the debian-cloud > mailing lists. I know the AWS images are announced to the list, and > peer reviewed. > > I can also say with certainty that both AWS and GCE went through an > initial public vetting on list. As for vetting images for unpopular systems, > I don't know the answer, but I think we can cross that bridge when we > come to it. > > Cheers, > Brian > >>> 4) Documentation? Is it enough to just put it in wiki.d.o, in the cloud >>> section? >> started on https://wiki.debian.org/MicrosoftAzure. >> >>> 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? >> >> The answer to this is quite simple: At the time we started to create images >> for >> Azure, bootstrap-vz was not in shape for generating Azure images that worked. >> For the demonstration purpose during DebConf15 we needed an image and Thomas >> openstack-debian-images script generated an image that was more or less out >> of >> the box usable for Azure. So we continued to use that script. Long term we >> plan >> to support both scripts. >> >> Best regards, >> >> Martin >> -- >> Martin Zobel-Helas >> Technischer Leiter Betrieb >> Tel.: +49 (2161) 4643-0 >> Fax: +49 (2161) 4643-100 >> E-Mail: martin.zobel-he...@credativ.de >> pgp fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B >> http://www.credativ.de >> >> credativ GmbH, HRB Mönchengladbach 12080 >> USt-ID-Nummer: DE204566209 >> Hohenzollernstr. 133, 41061 Mönchengladbach >> Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer >
