VM on osgeo4 for Metadata Repository

[arnulf]

The Mapbender project requests a dedicated VM on osgeo4, see at: ​http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2010#osgeo4

The server should be known as ​http://mapbender.osgeo.org (which currently redirects to ​http://www.osgeo.org/mapbender)

[arnulf]

The summary of the ticket was changed to: "VM on osgeo4 for Metadata Repository" to reflect the purpose of this instance. It is planned to use this VM as a permanent OSGeo resource providing a service metadata repository with monitoring and management capabilities. It is intended to be used to rivive the currently dormant Public Geospatial Data Committee Working Group on Geodata Discovery [1]. The Wiki page is simply not the right tool to get things done, it was created and used well initially but was abandoned when it grew too large to be useful.

[1] ​http://wiki.osgeo.org/wiki/Geodata_Discovery_Working_Group

[wildintellect]

It seems a more appropriate place for this might be on the webextra VM which already exists or on a to be created Projects VM. Is this ticket still connected to mapbender in any way?

[crschmidt]

Per our discussion today:

Since the Geodata Working Group is treated as a project of OSGeo, this work is ideal for the projects VM. After the meeting today, we have outlined the infrastructure for that VM, and will be getting it set up shortly.

Once the projects VM is up, access will be granted to the users who currently have access to the Telascience blades (via ldap); the people interested in setting up a Metadata repository can collaborate to get the software that they want installed and running on that machine.

[arnulf]

As an OSGeo-service (just like SVN, Trac or Wiki) metadata.osgeo.org has high availability requirements. Parking it on a general "projects VM" is asking for trouble. The load requirements are minimal compared to that of a build bot or large SVN commits as it only moves around URLs and other metadata.

A reliable linkage to OSGeo's LDAP is required.

[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
Systems Administration

[warmerdam]

Arnulf,

Per discussions on the sac mailing list OSU OSL has created a new "adhoc" VM. This should be suitable for use by the Mapbender SoC student for development purposes. It is accessable at:

adhoc.osgeo.osuosl.org

Anyone in the telascience LDAP group will have ssh access, and can use this url to add new people:

​https://www.osgeo.org/cgi-bin/auth/ldap_shell.py

Furthermore, I have given you sudo access, and you can grant sudo access (by adding people to the sudoers group in /etc/group) as needed on this system.

I have written up some notes at ​http://wiki.osgeo.org/wiki/AdhocVM

Note that the core mapbender website (​http://mapbender.osgeo.org) is still likely best hosted on the main Projects VM - intended for stable, mission critical services.