Re: Debian services and Debian infrastructure
]] Lucas Nussbaum
This mail has been maturing in my in- and outbox for a little while, and
it seems like the debate died down until the recent dda mail, so
restarting the underlying discussion a bit.
> Q1. How much should we push for Debian services (services useful to
> Debian) to be hosted on Debian infrastructure?
A lot.
> 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?
I don't think so. We've been pretty open with the requirements and the
reasoning behind the requirements. If those requirements don't apply
for some reason, we should fix the requirements and not work around them.
[...]
> The recurring pattern seems to be that, when DSA is approached to move the
> service to Debian infrastructure, their evaluation of the service's design
> results in changes requests or constraints that the service maintainers
> consider too hard to satisfy.
I don't think this is an accurate statement. There have been a few
cases where people have shown up with a design we were unable to
accomodate and progress have stopped, but in general there's been a
tremendous forward progress in what's hosted on DSA infrastructure. I
don't think it's ever been easier to get new services hosted on DSA
infrastructure in the history of the project. Examples over the last
six months are voip, tracker, manpages, contributors, and that's without
looking at any of the various static vhosts added.
No process is perfect, and while we should look at the cases where we've
failed to reach a conclusion leaving everybody happy, I think it's just
as, or even more important to look at the cases where we do have a happy
ending.
> 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?)
We've already talked about making d-a@lists public (but not older
archives). It's basically just somebody doing the work.
[...]
> 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.
Wiki pages are terrible for discussion, but having wiki pages (or
similar) for all our services, contact points and so on might be
useful. In practice, I think we're doing ok for any official services
since we informally know who runs a given service, though.
> 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).
In general, we're quite happy to create VMs for people when they show up
with a service they want to deploy, so I think this is quite well covered.
[...]
> > 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.
I don't think we should, simply because it either means one of two
things: a) DSA are too difficult to work with and our standards are too
high/too difficult to satisfy, in which case we should fix reality and
our standards to match up. b) the service is in bad enough shape that
it shouldn't be deployed on any infrastructure, since keeping it running
will cost too much (in terms of manpower, cpu power or whatever).
Deploying it on non-d.o infrastructure, as what you're describing it as,
it to route around DSA and we as a project have a problem when the
maintainer loses interest (and then often this becomes DSA's problem,
but with the additional problem of there being no design or operation
documentation, hard to get in touch with whoever runs the
infrastructure, security problems due to lack of maintenance, etc)
> 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.
Given we don't lack for computing resources, I think the answer to that
question is «mu», and I don't think we should be looking at this.
> > 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
Unless the service maintainer takes full-stack responsibility for this
(in which case, they're basically replicating DSA's job, which means
extra coordination costs), there will be security concerns. In fact, I
think any non-readonly service running on non-DSA-managed hardware, is a
security concern. Openssl.org is the most recent example of why.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: