Folks,
It looks like John Graham has replaced the failed disk in xblade 11 at
telascience (aka as geodata.telascience.org or 198.202.74.216). The system
is a fresh FC4 install with a roughly 25GB root partition and 85GB /data
partition. LDAP logins have not yet been enabled, and I believe all previous
work on this system is lost.
I have updated the notes on this system at:
http://wiki.osgeo.org/wiki/SAC_Service_Status#xblade11-2_.28geodata.29
But I have *not* updated:
http://wiki.osgeo.org/wiki/Geodata_processing_at_telascience.org
The question I have is whether we wish to re-establish this system as
a work system for the geodata committee or recycle it for some other purpose.
It appears we are also making extensive use of hypercube for geodata
serving though I have not followed that in any detail.
http://wiki.osgeo.org/wiki/HyperCube
I would personally like us to consider using geodata.telascience.org
to deploy dependable example instances of various OSGeo services. For
instance, I would like to use it for demonstration WMS, WCS and related
services based on MapServer, that I can point regression test scripts at.
It isn't imperative that a lot of data be available to serve for this role,
but it is imperative that the services setup be stable. If we take this
purpose for the server, I would also like to setup backups (likely by rsync
to osgeo2) so we could reestablish the services quickly if the machine
dies.
Some other possible uses:
o Geodata processing (as it is currently defined)
o Geodata serving (but it has rather modest disk space, and modest CPU
to do this on a huge scale)
o buildbot master/slaves (current buildbot blade may become build-saturated
if used for many more projects)
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
Frank Warmerdam wrote:
Some other possible uses:
o Geodata processing (as it is currently defined)
o Geodata serving (but it has rather modest disk space, and modest CPU
to do this on a huge scale)
o buildbot master/slaves (current buildbot blade may become build-saturatedif used for many more projects)
Folks,
Another possible use might be as an FGS build/distribution system. FGS
is a fairly brought suite of linux binaries in a cross-platform, easy to
deploy format (mainly aimed at the C/C++ stack). I have at times thought
it could be the "OSGeo4Linux", roughly comparible to what we are trying
to do with OSGeo4W on windows.
This use would not be incompatible with some other uses.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
Frank Warmerdam wrote:
Frank Warmerdam wrote:
Some other possible uses:
o Geodata processing (as it is currently defined)
o Geodata serving (but it has rather modest disk space, and modest CPU
to do this on a huge scale)
o buildbot master/slaves (current buildbot blade may become build-saturatedif used for many more projects)
Folks,
Another possible use might be as an FGS build/distribution system. FGS
is a fairly brought suite of linux binaries in a cross-platform, easy to
deploy format (mainly aimed at the C/C++ stack). I have at times thought
it could be the "OSGeo4Linux", roughly comparible to what we are trying
to do with OSGeo4W on windows.
This use would not be incompatible with some other uses.
Frank,
Any attempt to update the Buildbot farm with VM instances?
Are we strong enough in hardware to handle 2-3 VMs?
Greetings
--
Mateusz Loskot
http://mateusz.loskot.net
Mateusz Loskot wrote:
Frank,
Any attempt to update the Buildbot farm with VM instances?
Are we strong enough in hardware to handle 2-3 VMs?
Mateusz,
I'm not aware of any movement on VMs. The telascience blades (like
geodata.telascience.org) seem to have 1GB of RAM. This seem rather modest
to run multiple VMs. The 85GB of disk space could also be consumed fairly
quickly if we had several VMs with a variety of stuff in them.
I'm not sure if there is some beefier home available where we might be
able to run VMs.
"osgeo2" might be a good place to consider running some VMs. It has 4 CPUs,
2GB of RAM and 160GB of free disk space, and is generally lightly utilized.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
Frank Warmerdam wrote:
Mateusz Loskot wrote:
Frank,
Any attempt to update the Buildbot farm with VM instances?
Are we strong enough in hardware to handle 2-3 VMs?
Mateusz,
I'm not aware of any movement on VMs. The telascience blades (like
geodata.telascience.org) seem to have 1GB of RAM. This seem rather modest
to run multiple VMs. The 85GB of disk space could also be consumed fairly
quickly if we had several VMs with a variety of stuff in them.
Frank,
Yes, this is insufficient amount of RAM.
I'm not sure if there is some beefier home available where we might be
able to run VMs.
"osgeo2" might be a good place to consider running some VMs. It has 4 CPUs,
2GB of RAM and 160GB of free disk space, and is generally lightly utilized.
2 GB is not enough too. 4 GB is a reasonable minimum.
Some time ago John told me that there is a chance for more RAM and disk in future. So, I'm just asking to assure myself I haven't missed any motion in this matter.
Greetings
--
Mateusz Loskot
http://mateusz.loskot.net