[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian services and Debian infrastructure


I'm only replying on the main point I'd like to make, so I'm limited my
quoting to that. Do not take it as agreement or disagreement on the
other points -- I just consider them more minor points.

On 21/01/14 at 22:09 +0100, Tollef Fog Heen wrote:
> > 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.
> > 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.

It's great that you are quite happy to create VMs for people when they
show up with a service they want to deploy.

But that's not what I'm talking about. I'm seeking a solution for people
who show up with an *idea* they want to *experiment* with. Because:
1) that's when they should engage with DSA so that you have a chance to
   review/participate in the design, not months later when an unofficial
   service is up and running;
2) the alternative is that they give up on the idea, or host it
   themselves, which makes it harder to work collaboratively on the
   service, and results in services that have a single maintainer (or
   none, in the end).

A strong requirement for such a solution is that it should be easy
to get access to a VM, even if the developers do not have any working
code yet, or are not even set on all the implementation details of the
services (e.g.; a 10-lines description of what the service is about
should probably be enough).

Another requirement is that the developers should have root access on
the virtual machine, so that it's easy to try various options without
DSA intervention (remember: this is about developement/beta testing,
not about running the service in a super-stable, production mode).

Since we discussed that back in June, you added 'providing an OpenStack
cloud' on the DSA radar (it noticed that it was mentioned in the 'just
starting' category of DSA meeting minutes). Providing such a solution
on Debian hardware would be a great solution to the above problem.
Is there something you need from the DPL to make this a reality?

Also, a technical question (I'm curious): is there a technical reason
why it's not possible to do that inside the current Ganeti setup? Is
there something inherently less secure with providing root access to
a VM inside a Ganeti cluster, compared to providing root access to a
VM inside an OpenStack cloud? I'm asking because I don't expect a huge
demand for this (something between 5 and 15 VM per year), so that's
still a scale that could manageable using RT tickets + manual creation.

Finally, I'd like to re-state that hosting everything (including
development VMs) inside the Debian infrastructure is the most desirable
solution. However, it seems that it requires manpower and resources that
DSA does not really have for now (I would happy to help if possible with
the 'resources' side -- I can't do much about the 'manpower' side).
That's something we should work on so that ultimately, e.g. 1 or 2 years
from now, we reach that point.

But I don't think that we should wait 1 or 2 years to solve that general
problem. That's why I'm exploring a compromise and temporary solution,
which is using resources from public clouds. I will be very happy to
drop that solution as soon as we have a DSA-provided one.


Attachment: signature.asc
Description: Digital signature

Reply to: