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.
