#568: VM on osgeo4 for Metadata Repository
-----------------------------+----------------------------------------------
Reporter: arnulf | Owner: sac@…
Type: task | Status: new
Priority: major | Component: Systems Admin
Keywords: osgeo4 migration |
-----------------------------+----------------------------------------------
Comment(by crschmidt):
Arnulf:
"OSGeo-service" only has meaning if SAC takes on that role. You have
outlined it as:
* A replacement for mapbender.osgeo.org
* A project of the Geospatial Data group
* An OSGeo-service
OSGeo services are software services that SAC has taken on the task of
installing and maintaining. Since metadata.osgeo.org has, so far as I can
tell, not been described to SAC, there is no way that SAC could take on
the task of maintaining the software in question.
At this time, SAC is happy to leave the operation of the metadata service
up to the Public Geospatial Data project. If you wish to propose that SAC
takes on the running of a metadata repository as a foundation task (not as
a project task), then a more concrete proposal sent to the mailing list is
probably the right way to handle that.
As to your concerns about load/availability: The VM ('hardware') provided
for the metadata project, while shared with the other projects, is the
best-provisioned hardware that OSGeo has thus far made available; it has
been given the most disk space, CPU, and RAM of any VM that we make
available. It is the most important VM for OSGeo to maintain for public-
facing purposes, outside of the Drupal VM (for osgeo.org). Additionally,
the connection to OSGeo's LDAP is exactly the same for all of the OSGeo
services running on the VMs hosted at OSUOSL, so the projects VM is not
special in that regard. (This includes the main drupal site, SVN, Trac,
etc.)
If the projects VM is crowded, it will be SAC's responsibility to help
affected services move to other hosts, and we have already set up
monitoring of the services in question to ensure that we can observe and
be proactive in moving these services. If the projects VM is overloaded,
we will be happy to help migrate services to another VM; until such time
as a service demonstrates a need for a seperate host, it is our intention
to maintain most projects sharing infrastructure, maintained in
combination with SAC.
To sum up: If you want SAC to maintain it, you need to propose that to
SAC. (The answer may be 'no'; SAC is already completely overloaded with
the existing responsibilities, and adding more without more resources is
unlikely to happen.) IF you want the Geodata group to maintain it, then it
is in the right place, and if it turns out that it's the wrong place, SAC
will gladly help change that.
Best Regards,
Christopher Schmidt[[br]]
Systems Administration
--
Ticket URL: <http://trac.osgeo.org/osgeo/ticket/568#comment:6>
OSGeo <http://www.osgeo.org/>
OSGeo committee and general foundation issue tracker.