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 06:41:20 GMT

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!


> Best Regards,
> Dave
>> Gav...
>>> -----Original Message-----
>>> From: Dave Fisher []
>>> Sent: Friday, 9 December 2011 10:03 AM
>>> To:
>>> 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
>>>>>>> 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 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 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
>>> 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
>>>>>>> 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.

View raw message