> -----Original Message----- > From: Jürgen Schmidt [mailto:jogischm...@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:dave2w...@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 supp...@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. > > > >
