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 09:38:13 GMT


> -----Original Message-----
> From: J├╝rgen Schmidt [mailto:jogischmidt@googlemail.com]
> Sent: Friday, 9 December 2011 7:16 PM
> To: ooo-dev@incubator.apache.org
> Subject: Re: Extensions and templates
> 
> On 12/9/11 1:06 AM, 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.
> 
> Gavin, when you have it under control i would like to get access to it to
take a
> closer look on the internals, means the Drupal stuff. I hope i can find
some
> time to dive a little bit deeper into this stuff.
> 
> One to-do is definitely the upgrade to a newer Drupal version. I can't
promise
> anything but i will at least try to find the time...

sounds great, will create you an acct over the next few days.

> 
> But i have little experience with hosting and deployment of stable, secure
> running web apps. I can only help here and need help of more experienced
> developers in this area.

No problem

Gav...

> 
> Juergen
> 
> 
> >
> > 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