[Grok-dev] Re: Web site down

[Martijn Faassen]

Hi there,

Tim Terlegård wrote:
> On Jul 3, 2008, at 6:36 PM, Kevin Teague wrote:
> 
>> The server was rebooted this morning so that more memory could be 
>> allocated to the vmware image it's running in (from 256 MB to 512
>> MB).
> 
> During this short time two people on irc wondered why they couldn't
> use grok or grokproject.

We have learned we should be more careful with announcements at the very 
least, sorry about that again. I had not anticipated the impact of this 
upgrade.

> I think it would be good if we could make grok and grokproject not 
> depend on grok.zope.org being available. Perhaps we could add the
> latest versions.cfg to grokproject when we do a grok release? Then
> the extends line in buildout.cfg can use this versions-0.13.2.cfg.

While the new version of grokproject in trunk is still dependent on 
grok.zope.org, it does copy the versions file into the project if I 
recall correctly, meaning that actually installed projects should 
continue to work.

I'm not sure whether we should make the next step and make grokproject 
independent of grok.zope.org. Perhaps a caching approach would make 
sense? I.e. if grok.zope.org cannot be reached, it'll fall back on a 
cached version of the versions.cfg that it has somewhere. Someone 
willing to make a launchpad issue for this?

> Just a thought. It's nice to get rid of a single point of failure.

Agreed, though we're actually trying to get to a situation with a single 
point of failure which is grok.zope.org... In non-trunk grokproject, 
downloading the dependencies might mean the accessing of many sites, as 
some of the code is not actually hosted on pypi (it's only linking to 
the real page). Trunk grokproject is able to download a tarball with all 
dependencies. It gets this tarball from grok.zope.org, our single point 
of failure. :)

It's actually better to have one single point of failure we have some 
control over as opposed to dozens of them, after all.

Regards,

Martijn