Re: Debian services and Debian infrastructure
]] Lucas Nussbaum
> 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.
fairy nuff.
> > > 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;
They don't need a VM to do this, though.
> 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).
How does having a random VM running in a cloud somewhere make that
service easier to integrate into the wider debian.org setup? I don't
think it does; what does is the first point: talk to us so we can figure
out what works for both sides. Especially given you want to give root
to developers on those VMs, there's absolutely nothing that points in a
direction of those VMs being more integrateable than a service developed
on a developer's own laptop (in a VM or in their regular environment).
> 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).
We expect people who maintain packages to provide their own development
environment. How is service development qualitatively different? As I
said, we're happy to hand out VMs to people, but as you rightly point
out, the time when that happens tend to be when you at least have a
proof of concept running, not when you start thinking about how to solve
a problem.
> 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).
Who's then to ensure that machine is secured and kept up to date with
security patches and doesn't become a source of spam? Sorry to say, but
most developers are not good sysadmins and they do not have the tools
and infrastructure set up to do systems maintenance well. For this to
be an option at all, we'd want to sandbox the machines heavily enough
that they will be less attractive machines to develop on than a
developer's own laptop.
> 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?
It's sgran who's been thinking about how to do this, but afaik he's seen
close to zero interest from developers for it, so it's not happened
yet. I don't think we need anything from the DPL as such, but if people
are actually interested in something like this happening, saying so
would be a good start.
The lack of feedback worries me a bit, since one one hand it seems like
you're pushing quite hard for a cloud and all that, yet we're not seeing
a user demand. It could be that people don't approach DSA for whatever
reason (if so, we should fix that), but doing lots of work for something
we don't know if it's needed doesn't sound like a good use of our time.
> 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.
Given it's all just KVM, there's little to no difference,
security-wise.
> 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.
We have a rolling five-year plan for our hardware replacement schedule
which I'm sure you're familiar with. As long as we keep up with that, I
don't foresee any particular problems. If somebody shows up with a huge
service that might change, but as it is now, we're quite ok,
resource-wise.
> 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.
There's no solution as permanent as a temporary solution.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: