Dave, I already have access and have been speaking with Lance over this over the past week.
It is in hand, as they say. Gav... > -----Original Message----- > From: Dave Fisher [mailto:[email protected]] > Sent: Friday, 9 December 2011 10:03 AM > To: [email protected] > Subject: Re: Extensions and templates > > > On Dec 8, 2011, at 4:00 AM, Andrea Pescetti wrote: > > > Gavin McDonald wrote: > >>> From: Andrea Pescetti > >>> On 29/11/2011 Rob Weir wrote: > >>>> ==Option 1: Remain at OSUOSL== > >>>> We could remain with OSUOSL hosting. However, the existing site is > >>>> very unstable. > >>> This would be best both for short and long term. ... > >> Sorry, OSUOSL don't want anything to do with these any longer > > > > As I wrote, Options 1 and 3 (i.e., staying with OSUOSL or cloning to another > host) are fundamentally equivalent to me. My point is that the best first step > is starting from the current websites or a clone of them. > > > >> The hosts themselves cannot cope with all the memory and cpu these > >> are consuming all the time, let alone the bandwidth. > > > > Then someone should explain why they were absolutely stable in 2010, > with a traffic that can be safely assumed to be similar to the one they are > receiving in 2011. Something broke, and since the Drupal code hasn't > changed I still think that the malfunctioning components are somewhere else > (or, if in Drupal, not in the site itself but in the interface to caching engines). > > Send an email to [email protected] and start a conversation with Lance > Albertson. He's willing to tell you all about it. The short answer is that Oracle > was making changes when the plug was pulled on OOo. They left it broken. > > The other part is that the two sites were in such a state that OSUOSL's Nagios > checks on E&T were like Peter, the boy who cried wolf. They turned them off > and they don't notice when varnish gets frozen. > > Possibly with a little care you may be able to fix this. > > >> I've had a look around > >> the drupal sites and it is not optimal to say the least. > > > > It would be helpful to know what level of access you obtained to make this > assessment. Could you read the site code, or did you receive administrator > credentials for the website, or did you get shell access to the machine? > > > > That the sites are not optimal is fairly obvious, especially considering that > Extensions is a Drupal 5 site and thus creates sessions even for anonymous > users; Drupal 7 is much better in this respect and offers more scalability out > of the box and better integration with caching engines, so it seems a natural > candidate for medium-term and long-term improvements ("Option 5"). > > I don't see any reason why you shouldn't ask osuosl.org for access. > > If you and Gavin can both look then we are the correct path to resolving > these troubles. Just agree to work it through! > > Best Regards, > Dave > > > > > >>>> ==Option 2: Move Critical extensions to stable host== > >>> Indeed, as you write, this would be an extreme option. > >> More extreme would be to do nothing, as you'll end up with nothing. > > > > Of course. What I meant to say was: cherry-picking "important" extensions > and creating a repository for them from scratch is more or less the same > work of Option 1 or 3 (i.e., fix the current site or a clone of it) for a much less > interesting result. > > > >>>> ==Option 3: Clone OSUOSL repositories to another host== > >>> This is not significantly different from Option 1; i.e., if there > >>> are other hosting options available the mere cloning of the site > >>> would not take long, but again the problem is not with the site but with > caching. > >> Do not blame caches for poor performance. the caches are improving a > >> bad situation > > > > OK, no matter what we think about the root cause for the current bad > performance it seems that we both agree that cloning the site will give us the > possibility to tweak it (or the environment) and improve performance. Since > I've seen it working perfectly in 2010, I'm confident this is achievable. > > > >>>> ==Option 4: Host repositories elsewhere, using new UI== > >>> As I used to say, everybody who thinks that the Extensions or > >>> Templates sites can be replaced easily has never tried submitting a > template! > >>> Thorsten did a lot of customization work on the two sites; any > >>> replacement would provide a largely inferior user experience. > >> I think you don't think very highly of other peoples abilities, a poor > outlook. > > > > That was just a warning: people should know (and they would know, if they > had ever uploaded a template...) that the sites extract and use a lot of > information specific to OpenOffice.org and ODF files. This is often overlooked > when people see these sites as "some form of file repositories" and propose > to rely on different solutions: they should be aware that, to provide an > optimal user experience for our use case, a significant amount of custom > code must be added. > > > >>>> ==Option 5: Re-architect the Repositories== This is the option I > >>>> personally favor for long term. ... > > > > OK, it seems we have agreement, at least at broad scope, that the long- > term solution will be along the lines of Option 5 (i.e., encourage or enforce > external hosting; allow for a scenario involving several different repositories). > > > >> here is the route I intend to take: > >> 1. Move the services to a newer more modern host at the ASF > >> (temporary) 2. BandAid the installation to stabilise it for the short > >> term (this is still more work than it sounds) > > > > So it seems we agree on these steps, and it's great (for planning Step 1) > that you have access to information that is not available to me. > > > >> 3. Stick Apache TrafficServer in front (not varnish) to improve response > times / caching. > > > > I don't have enough knowledge on Apache TrafficServer to comment on > this specific step. > > > >> 4. Go with the choice of Option 5. that is, to allow the hosting and > downloading of the templates > >> and extensions to be with the 3rd party authors. > > > > It's already allowed; it is just not enforced. I mean, it already happens that > some extensions form the Extensions site are downloaded from external > sites like SourceForge. > > > >> the status quo can not continue, for benefit of all. > >> Help welcomed at any step of the way. > > > > Just make sure to get permission to transfer and modify the site code from > Oracle, or clarify that such a permission is not needed. I can't have any active > involvement with this until this issue is solved, even though I completely > share your desire to bring the sites back to normal operations as soon as > possible. > > > > Regards, > > Andrea.
