Re: Debian services and Debian infrastructure
Hi,
On Sat, 04 Jan 2014, Lucas Nussbaum wrote:
> I've given some thought to this myself, and came up with the following
> ideas. Some of them are probably really bad ideas, but let's try to
> brainstorm a bit:
I don't find them bad. At least from the POV of view of a DD and of a
service maintainer, they seem to go in the right direction.
> 1. to improve communication between DSA and service maintainers
> + have an archived, public list where (prospective) service maintainers
> can engage with DSA about stuff they are planning/thinking about.
> (Maybe recycle debian-admin@l.d.o, or use debian-services-admin@l.d.o?)
debian-services-admin@l.d.o seems to be rather appropriate for this (it's
unlikely that this kind of discussion would generate so much mail that the
list could no longer serve its current purpose).
> + have DSA provide collective answers more often, rather than a set of
> individual answers. It's often not clear if something is a final
> decision, or the opinion of a DSA member.
> + redirect some discussions from IRC to a mailing list, esp. when
> things look like policy decisions (on service design, etc)
It would also be helpful to have a document explaining their usual
requirements. It would pro-actively direct the service maintainers towards
choices that are acceptable to DSA.
Things like:
- use PostgreSQL if you need a DB
- keep in mind that DSA likes to ensure high-availability, so make it easy
to run a replicate of your service
- avoid dependencies not in stable or stable-backports
- avoid X, Y, Z for security reasons
- etc.
> 2. to improve the tracking of services
> + request wiki pages from maintainers that detail who are the contact
> points, what the service does, what are its requirements. State a
> "service level agreement" (informative of expectations, not punitive,
> of course)
> + have service maintainers create similar pages for services in
> development, to provide some kind of "incubation process" during which
> DSA can provide feedback.
This would be good to have but (someone|DSA) would have to prod service
maintainers to get this started, otherwise it will never happen. This
requirement could also be mentioned in the document I suggested earlier.
> 3. to provide a place to experiment with new services
> + create a "Debian cloud" with virtual machines to develop new services
> (maybe providing manually-created VMs would be enough -- I'm not sure we
> need a complex infra such as OpenStack).
I think we're already close to this at least in terms of creating virtual
machines for new services. I got one created rather easily and several
others were added recently.
That said a Debian cloud for short-lived Debian tasks is still an
interesting ideas, possibly in relation with PPA and having the
possibility to rebuild packages against a PPA.
> > Q1. How much should we push for Debian services (services useful to
> > Debian) to be hosted on Debian infrastructure?
>
> Fragmentation in terms of hosting is harmful, and we should all try to
> get our services hosted on Debian infrastructure, because that's the
> easiest way to ensure that the maintainance of such services can be shared
> or transferred between developers.
>
> Now, for some services, it seems that doing this has become so hard that
> it harmed the service itself, and badly demotivated the service
> maintainers. I don't think that we should allow that to happen. We should
> stay open to other hosting solutions, when this is necessary.
Having stuff hosted on DSA-managed hardware seems like something important
to me. That said we can't force all services to be ready to meet DSA's
requirements from day 1. So my suggestion would be have DSA allocate VMs
to host services in incubation and keep those services in the .debian.net
umbrella until they are ready.
There's always going to be exceptions (stuff needing so much resource
that it's unrealistic to allocate them out of the current hardware pool)
but that's OK. Those can be dealt on a case by case basis and are likely
to benefit from early interaction with DSA.
> > Q2. Should we seek other hosting opportunities to ease Debian services
> > development and hosting? Should I authorize the use of Debian money to
> > fund infrastructure not managed by DSA, in the case of a useful service
> > that DSA has been unable to accept in the infrastructure it manages?
>
> For services development (something for which we don't have a good
> answer yet), I think that we should explore getting specific sponsored
> hosting. As you know, Amazon provides Debian with free credits on the
> AWS Cloud. Those credits are normally used for archive rebuilds, but
> have already been used by a GSOC project (PTS rewrite), and more
> recently, to start work on an archive-wide autopkgtest setup. A few more
> virtual machines could be accomodated, and I will investigate if we
> could extend that even more. Also, codesearch.d.n is hosted on
> Rackspace's Cloud[1]. I will also follow up on that.
> [1] http://people.debian.org/~stapelberg//2013/12/25/codesearch-rackspace.html
>
> Question to DSA: would you be willing to manage the allocation of
> virtual machines on such cloud infrastructures? That would ease the
> monitoring of which services are being developed, and help with getting
> involved early in the design process.
That looks a good idea as well.
> > Q3. What should be our definition of "official services"?
>
> [ The debian.org DNS domain name is often associated with "official"
> services, whereas the debian.net DNS domain name is often associated
> with "unofficial" services. Besides the d.o/d.n distinction, I'm not
> aware of another definition of "official services" in Debian ]
>
> Even if this is highly preferable, I don't think that official services
> (.d.o services) should necessarily be running on Debian hardware managed
> by DSA, provided that:
> - the service is clearly useful and used
> - the service has a sustainable maintainance model (active team +
> instructions on how to contribute, run a local copy, etc. + DFSG-free)
> - the service's design does not raise security or scalability concerns
I do think that it's best if all the hardware we have is managed by DSA
(and thus owned by SPI or any other trusted organization). That said I
don't believe that DSA should necessarily administrate (i.e. be root) on
all the VMs that are running on our hardware (although that should be
the case when there's no reason not to).
We already have alioth.debian.org which is managed by a separate set of
admins and I would be perfectly OK with having some VM managed by the
developers who are hosting their service in incubation on that DSA-provided
VM.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
Reply to: