Okay, thanks Prasanna!
On 17 April 2013 07:44, Prasanna Santhanam <t...@apache.org> wrote: > On Tue, Apr 16, 2013 at 02:07:45PM +0100, Noah Slater wrote: > > Okay, some success. > > > > Here is a mail sent to infrastruct...@apache.org: > > > > On 16 April 2013 13:44, Tony Stevenson <pct...@apache.org> wrote: > > > > > Noah Slater wrote on Tue, Apr 16, 2013 at 01:33:39PM +0100: > > > > Hi, > > > > > > > > It recently came up on the CloudStack list that if cloudstack.orgmoves > > > > over to ASF control, we would not be able to point > foo.cloudstack.org at > > > an > > > > external VM. (Say, a committer is running a CI/build/whatever > service.) > > > Is > > > > this the case? Are there any exceptions to this? > > > > > > > > I ask not because I want to drag up old discussions for the sake of > it, > > > but > > > > because we have some ongoing trademark stuff with CouchDB, and one > of the > > > > things I am planning to propose is that we move couchdb.org to ASF > > > control. > > > > > > > > But if the above is policy, that wouldn't work. > > > > http://docs.couchdb.org/points at a third-party hosted service, for > > > > instance. And we are working on > > > > a Jenkins setup that is not on ASF hardware (because the ASF is > unable to > > > > provide us with the hardware we require at this time). > > > > > > > > Could someone clarify this for me? > > > > > > Noah we have several instances of DNS records pointing to non-ASF > hosted > > > services. We would clearly very much prefer that we didnt have to do > > > this, but I do not believe it is against policy. > > > > > > Our issue comes from the fact the machine is not under our control, and > > > as such anyone could just add $bad-content within the apache.org > > > namespace. At the moment, from memory, all records that point to > > > non-ASF hardware, are still machines we control. Your asking for > > > something above and beyond this, and I suspect if this is what the PMC > > > wants then that would be done. But it would need to be requested, > > > following a vote thread and that link given to us so we can see the > > > process :) > > > > > > > This is from a private list, but I have been granted permission to share > it > > with this one. > > > > For those with the appropriate karma, the thread starts here: > > > > http://s.apache.org/ZLE > > > > So, if we put together a definitive plan of action for the domain, and > the > > services we want to host / point to, along with who is operating them, > and > > what the plan for that is, and vote on it, it looks like we can proceed. > > (But we should be mindful of Infra's concerns, and take them into account > > while drafting the proposal.) > > > > Thanks Noah. That helps clear some confusions. But I've moved jenkins.cs.o > to a different namespace as was done before with docs.cs.o. > jenkins.cs.o now resides at jenkins.buildacloud.org. One of the > difficulties for moving our jobs to builds@ was the performance and > hardware considerations. > > I think some infra@ folks are aware of the problems we have with > having to stack up enough hardware to run tests for our system. Having > a separate managed jenkins is useful for us to quickly fix problems as > is often the case with automated testing. Some of the other cs.o services > are managed by David and myself. David has the necessary karma within > infra to look into these when things go bad. > > Unless others feel that the services should remain on cloudstack.org I > think we have a reasonable backup plan for now. Anyone think > otherwise? > > -- > Prasanna., > -- NS
