I'll volunteer to help out on supporting the machines.
I haven't been able to to much useful TCK work since my most powerful
available system is a laptop that gets restarted twice a day.
Jay
Joe Bohn wrote:
All,
We have discussed in the past the idea of getting some ASF hosted
machines that we can use to run and share TCK test results for Geronimo.
With more folks coming on board running TCK tests this seems to be
getting more and more important. It would also be great if we could get
some of the automation working again on these dedicated machines ... but
I think we need to secure some machines first. For now, I think we
should just get something we can share for Geronimo with an eye toward
possible sharing across other ASF projects in the future.
Some recent discussions with infra indicate that the Geronimo PMC needs
to submit a proposal for these machines if we ever hope to get some. The
proposal must meet the criteria listed below in addition to some more
obvious things such as the number and specifications of the machines.
The Geronimo PMC must approve and then make the request to ASF infra but
we can discuss the requirements here and formulate the proposal. Please
jump in if you have opinions on the specs and number of machines. Keep
in mind that we need to keep this request reasonable if we have a hope
of getting it accepted. I also imagine that we'll have to volunteer
some people to help manage these machines .... volunteers?
I'll start to put together a proposal with your input and when we think
it is complete enough I'll forward it to the PMC for further action.
The sooner we can get this proposal pulled together the better off we'll
be.
Does anybody have a sample proposal for something similar from infra?
I'm not sure how detailed this proposal must be.
Thanks,
Joe
ASF infra checklist:
---
This provides a list of requirements and doctrines for web applications
that wish to be deployed on the Apache Infrastrcture. It is intended to
help address many of the recurring issues we see with deployment and
maintainence of applications.
Definition of 'system': Any web application or site which will receive
traffic from public users in any manner.
Definition of 'critical systems': Any web application or site which runs
under www.apache.org, or is expected to receive a significant portion of
traffic.
1) All systems must be generally secure and robust. In cases of failure,
they should not damage the entire machine.
2) All systems must provide reliable backups, at least once a day, with
preference to incremental, real time or <1 hour snapshots.
3) All systems must be maintainable by multiple active members of the
infrastructure team.
4) All systems must come with a 'runbook' describing what to do in event
of failures, reboots, etc. (If someone who has root needs to reboot the
box, what do they need to pay attention to?)
5) All systems must provide at least minimal monitoring via Nagios.
6) All systems must be restorable and relocatable to other machines
without significant pain.
7) All systems must have some kind of critical mass. In general we do
not want to host one offs of any system.
8) All system configuration files must be checked into Subversion.
9) All system source must either be checked into Subversion, be at a
well-known public location, or is provided by the base OS. (Hosting
binary-only webapps is a non-starter.)
10) All systems, prior to consideration of deployment, must provide a
detailed performance impact analysis (bandwidth and CPU). How are
techniques like HTTP caching used? Lack of HTTP caching was MoinMoin's
initial PITA.
11) All systems must have clearly articulated, defined, and recorded
dependencies.
12) All critical systems must be replicated across multiple machines,
with preference to cross-atlantic replication.
13) All systems must have single command operations to start, restart
and stop the system. Support for init scripts used by the base
operating system is preferred.
