[Pharo-project] Metacello --- How to make sure that we will be able to load... in 3 years from now
janko.mivsek at eranova.si
Tue Feb 23 16:25:46 EST 2010
What if use redudancy features of Internet itself? As you know the
Internet was designed to withstand a nuclear attack, with a lot of
redudant features, which we can explore to harden the Smalltalk
infracture as well.
In the similar ways as guyss like Google do. You know, they have always
a single entry, http://www.google.com, but actually they direct your
search to 1000s and milions of their servers behind. A mini version of
Google can be use for Squeak or PharoSource as well.
As I can see the Monticello repositories are basically the stateless
WebDAV enabled Apache web servers. So having a mirror is a first thing
to do. To still have a single entry point like
http://www.squeaksource.com), we can exploit the redundancy feature of
DNS: round robin entries. That is, you enter two entries in DNS zone,
with the same name but different IP addresses, say:
www IN A 126.96.36.199
www IN A 188.8.131.52
This way in the case of failure of one server, the another one will
responds. If both are working, DNS will return one of them in roun robin
This will work for WebDAV part of the story, but we still need to tackle
of the statefull web application of SqueakSource... hmm, a bit more
thinking is needed therefore...
On 23. 02. 2010 19:48, Dale Henrichs wrote:
> I like the notion of a secondary repository for packages. It is absolutely necessary to protect us from a catastrophic failure with any one of the SqueakSource repositories.
> Perhaps Gofer can be provided with a secondary repository location in the case when the primary repository fails.
> With this kind of approach, the metacello configurations can continue to reference the primary development repository, in this way we might just be able to have our cake and eat it too:) The Pharo secondary repository would protect users from repository volatility and package volatility ... Once a version is published in Pharo you can count of being able to load that version over time.
> This secondary repository could be maintained by periodically scanning the Pharo configurations and copying the referenced packages from the primary repository to a known secondary repository (this repository could just be done with Apache file access since a fancy UI for the secondary repository isn't essential).
> Having code and processes in place means that individuals can reuse the code and process to maintain their own secondary repository for their own production environment.
> I have code that does most of what is needed, as I use this process at GemStone for archiving the configurations and mcz packages in our company source code control system.
> ----- "Göran Krampe" <goran at krampe.se> wrote:
> | Miguel Enrique Cobá Martinez wrote:
> | > El mar, 23-02-2010 a las 11:14 +0100, stephane ducasse escribió:
> | > I was thinking about this problem yesterday in the light of the
> | packages
> | > moved by Lukas.
> | > We have a problem with the packages referenced by a
> | ConfigurationOfXXX.
> | > The can disappear anytime. The repository can disappear anytime.
> | >
> | > So I thought that we need a dedicated hosting server where:
> | >
> | > - We have all the ConfigurationOfXXX (in the MetacelloRepository
> | repo,
> | > just as now)
> | > - We copy there *all* the packages that conform a giver
> | > ConfigurationOfXXX>>versionXX: from the original repo to this
> | dedicated
> | > repo.
> | > - There is *no way* to delete anything. This is a *write only, read
> | > always, delete never* repository.
> | Sidenote: SqueakMap actually caches all URLs used for versions and if
> | the original URL fails an SHA check it falls back on the cached file
> | on
> | the SqueakMap server.
> | In that way it was meant to handle original URLs going stale or
> | disappearing.
> | regards, Göran
> | _______________________________________________
> | Pharo-project mailing list
> | Pharo-project at lists.gforge.inria.fr
> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Svetovalec za informatiko
tel: 01 514 22 55
faks: 01 514 22 56
gsm: 031 674 565
More information about the Pharo-dev