On Dec 8, 2011, at 4:35 PM, Dave Fisher wrote: > 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!
I forgot to mention buildbot support! Dave > > 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. >> >> >
