incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Pescetti <>
Subject Re: Extensions and templates
Date Thu, 08 Dec 2011 12:00:45 GMT
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).

> 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").

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


View raw message