On 21/01/14 at 15:07 +0000, Stephen Gran wrote: > I think there's quite a range of options between "DSA can't host > everything under the sun" and "I'll go set up a private parallel > development environment out of project funds without any further > discussion".
I don't know who you are quoting here, but I never said that "I would go set up a private parallel development environment out of project funds". What I'm doing currently is what I wrote in the mail you replied to: > > However, it sounded pointless to argue on that if there is no concrete > > offer to host Debian's services being developed outside of Debian > > infrastructure. So, since that discussion, I've been talking to a few > > hosting providers, and two of them have offered to support Debian with > > free resources (on their clouds) for Debian development. Since I think > > that avoiding vendor lock-in is a must, I'd like to make sure that we > > can get a third one on board before working out further details. That is, *explore the possiblity* to get *free* resources for Debian development. > > Now, of course, I'm very disappointed that nobody from DSA is interested > > in acting as a gateway between service developers and hosting solutions > > outside of Debian infrastructure that would be suitable for services in > > development and experimental/maturing services. In my eyes, that would > > have been a win-win situation, by putting DSA in the perfect position to be > > aware of emerging services, and to interact early with service maintainers. > > But, well, I cannot force anyone to do work that they don't want to do. > > So, I offered at one point to set up an openstack private cloud for DDs > to use for service development and so on. I got almost as enthusiastic > a response to that as we got to kerberos, AFS, and now MQ. I decided > to let it go instead of putting lots of energy into something that no > one would use. That sort of thing can be revisited if it's actually > interesting for people. FTR, I agree that the demand will not be huge for that. Probably in the order of 4-8 services hosting requests per year. However, I disagree that no one would use that. I know of at least two services using VMs on EC2 for service development currently. If we can avoid spending DSA's time on a private OpenStack Cloud by getting free resources, and solve the problem of providing a development infrastructure that way, I really think that this is the way to go. > I'm not sure what you picture when you talk about us acting as a > gateway. Perhaps you could elaborate on that. I'm not keen on playing > script monkey to set up machines for people - I'd much rather that > interested people be able to do that for themselves. If you just want > us to be a point of contact for people developing new services, I think > we've said several times that we'd like to be just that. I think that the tasks involved would be something such as: - Work with hosting providers so that we have some diversity in the offerings, and avoid vendor lock-in. - Understand the offerings (what's available? possible?) - Document the various offerings (wiki page) - Understand what prospective service maintainers are asking for, in terms of resources. Maybe provide advice on design. - Do the matching between what service maintainers need and the hosting providers - Maybe provide some support to service maintainers (e.g. for dealing with the specifics of each hosting provider) - Maybe make it possible to install DSA-flavored VMs on the various Clouds, using the resources pointed to in [1]. [1] http://lists.debian.org/20140109083128.ga12...@varinia.lobefin.net There's nothing here that *needs* to be done by DSA, but it would certainly be very helpful to have DSA members involved. > > However, it sounded pointless to argue on that if there is no concrete > > offer to host Debian's services being developed outside of Debian > > infrastructure. So, since that discussion, I've been talking to a few > > hosting providers, and two of them have offered to support Debian with > > free resources (on their clouds) for Debian development. Since I think > > that avoiding vendor lock-in is a must, I'd like to make sure that we > > can get a third one on board before working out further details. That > > will include deciding how allocation of such resources happen, and where > > discussion about this should happen. My first choice would be to use > > debian-services-admin@ for that, but of course that will be your decision > > as I don't want to 'pollute' the list with traffic you are not interested > > in. > > No, that's precisely the sort of thing the list is for, I thought - it's > not a private list for DSA or anything. Not sure where the word pollute > or its scare quotes have come from, but it sure feels hostile. I'll > assume you don't mean it that way. Well, if DSA has nothing to do with this development infrastructure they don't host, it could have made sense to have a separate list for that, just to keep the signal/noise ratio high for services hosted on DSA-managed infrastructure. That's why I clearly don't want to push that on you. Similar to #debian-admin vs #alioth. > I have some operational questions about this cloud setup, since it seems > you've delegated running Debian owned machines to us and then gone and > got some that you don't want us to run. I'm not sure what to do with > that disjuncture. I don't know what you are talking about. Where did I "got some Debian owned machines that I don't want DSA to run?" Lucas
signature.asc
Description: Digital signature
