[Grok-dev] Re: Web site down
faassen at startifact.com
Fri Jul 4 06:17:29 EDT 2008
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
> 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
> 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.
More information about the Grok-dev