incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gavin McDonald" <ga...@16degrees.com.au>
Subject RE: Extensions and templates
Date Fri, 09 Dec 2011 00:06:08 GMT
Dave,

I already have access and have been speaking with Lance over this over the
past week.

It is in hand, as they say.

Gav...


> -----Original Message-----
> From: Dave Fisher [mailto:dave2wave@comcast.net]
> Sent: Friday, 9 December 2011 10:03 AM
> To: ooo-dev@incubator.apache.org
> 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 support@osuosl.org 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.



Mime
View raw message