Gavin, On Dec 8, 2011, at 4:06 PM, Gavin McDonald wrote:
> Dave, > > I already have access and have been speaking with Lance over this over the > past week. > > It is in hand, as they say. Yes! And we all appreciate this (or should!). Forums - check, MWiki - check, other wikis - check, Roller - check! You do a lot to support AOO, you have a track record. Thank you, Gavin! Best Regards, Dave > > 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. > >
