[SAC] Re: [OSGeo] #568: VM on osgeo4 for Metadata Repository

[OSGeo]

#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.