Hi, <disclaimer> 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. </disclaimer>
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. Lucas
signature.asc
Description: Digital signature
