incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Extensions and templates
Date Fri, 09 Dec 2011 00:03:15 GMT

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

Send an email to 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

I don't see any reason why you shouldn't ask 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,

>>>> ==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
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 /
> 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.

View raw message