A conference call is planned for 21 September 2007, Friday, 12:00PM-1:00PM (Eastern US time) using the Sakai001 Conference Bridge. (|#Agenda)
With the beginning of the semester behind us at many Sakai organizations, it seems like a good time to gather as a community and share our production experiences. For many, it was the first time in production with 2.4, and for some a bumpy road, with important lessons-learned from which the rest of the community could benefit.
If you plan on attending, please let me know, Peter A. Knoop. If there is sufficient interest, we can turn this into a regularly-scheduled occurrence going forward.
The Conference Bridges support both network (e.g., Polycom, XMeeting, NetMeeting) and telephone connections.
Sakai001 (Scheduled Meetings)
Conference Code: 348
IP Address: 126.96.36.199
More detailed directions for connecting can be found at the Sakai Conference Bridges site on Collab.
If you have topic you would like to see on the agenda, please contact Peter A. Knoop.
Focus is on how 2.4 is handling from a sysadmin and dba perspective.
- Sakai Production Deployment Database – make sure your listed and that your information is up-to-date
- Jira Filtes: Production Deployments
- Email lists: firstname.lastname@example.org versus email@example.com
- Should we make an effort to partition topics approrpriately betweeen lists?
- What does 'dev' versus 'production' mean to you?
- Posting of local reports to the group
- What are the "lessons-learned" from your recent experience?
- What are some of the performance, load, scalability, robustness, etc. issues that have been a challenge with the current 2.4 release (and past releases, if relevant)?
- How can we better foster communication and collaboration among schools?
- What's the best way to get the word out about a problem so others have a heads-up?
- Are there key Jiras in the 2.4.x maintenance branch that you found essential in addressing your problems, and which the community should be made aware of?
- Production Statistics
- What defines a "big" versus "small" deployment? Is it just "big stats"? Is a small group of users on limited resources likely to run into the same performance and scaling limitations as a big group of users on lots of resources?
- What statistics do you for your resource planning?
- Do you have these statistics for your deployment?
- total disk usage for database at the end of each semester
- total disk usage for filesystem storage at the end of each semester
- typical peak newtork bandwidth usage during each semester
- average network bandwidth over the course of a semester
- typical peak web hits per <some time interval>
- number of sites created per semester
- total number of active users each semester
- typical peak concurrent user sessions during each semester
- Strategies for using 2.4.x in production.
- Deployments need to be based on Maintenance Branch?
- How do you decide which "fixes" to pick-up?
RSVP'ed they'll be there:
- Georgia Tech (Clay Fenlason)
- Indiana University (Lance Speelmon and others)
- Rice University (Omer Piperdi, Angela Dehart Rabuck)
- RSmart (Hannah Reeves)
- Stanford (Casey Dunn, Julian Morley)
- University of California - Berkeley (Oliver Heyer and others)
- University of California - Davis (Thomas Amsler and others)
- University of Cambridge (Ian Boston and others)
- University of Michigan (David Haines, John Leasia)
- Unicon (Chris Franz)