Infrastructure Working Group

This is a proposal for a Working Group to assess OSGeo's software infrastructure needs and provisions.

Focus

• Assess the OSGeo community's needs for code management and collaboration tools, particularly collecting requirements and feedback from the Incubation Committee and Website Committee
• Plan for the software and data repository facilities to be hosted at telascience
• Plan for the administration of telascience facilities
• Offer recommendations on future development directions to the Board

Participants

• Frank Warmerdam
• Jo Walsh
• Tyler Mitchell - suggested
• Cameron Shorter - suggested
• Bob Bray - suggested

=== Members who defected to the System Administration Committee

• Schuyler Erle
• Norman Vine
• Howard Butler
• Arnulf Christl
• Please add yourself

Meetings and discussions

• When there's enough to chat about, suggest a chat session time (perhaps one that works well with the existing Website Committee timings?
• If necessary, start a mailing list
• "irc://irc.freenode.net/telascience"

Documents

• Project Infrastructure Migration is a very comprehensive overview of what tools the individual software projects are using now, both to manage their codebase and their communications.

• WebCom OSGeo Site Focus is a collection of site visitor use cases; when people come to the public front, what do they expect and need to find from OSGeo?

• Geodata Repository is an overview of what metadata / archiving / redistribution facilities people have discussed wanting to offer through OSGeo

• Software Stack is a collection of notes on what OSGeo software can be made available as a "demo stack" hosted on the telascience system.

• OSGeo.org Subdomains list

Use Cases

Non-software/operations Committee use case

The Geodata committee is the first attempt at moving forward on a non-software project Committee that isn't concerned with OSGeo internal operations, so we are figuring out a lot as we go along.

• Wiki works well for sketching out rough requirements and for planning stages
• Wiki doesn't work well as a shared editing environment for pages which are destined to go onto the "Official" site - e.g. Geodata Homepage Draft
• We need some way to get multiple authors working on pages for the "official" site, without having to check them back into a live repository on subversion, or branch the pages and then re-merge them...

Auto Build / Smoke Test

Some of the software projects need a place for doing automated builds and smoke tests. Ideally at least one system would be as decked out as possible with additional components such as PostGIS, Oracle, MySQL and so forth, so we can test these.

FrankW suggests this should be a service hosted on telascience OSGeo system(s)

System Administration

Working Group

OSGeo systems (outside CollabNet) will need a system administration group of some kind. That might be a formalized version of this working group (though this group is pretty focused on assessing needs rather than building out systems), a new committee (or working group) or possibly a working group within WebCom (taking their mandate broadly). For the time being lets call this group the OSGeo System Administration Working Group.

It will need to consist of trusted volunteers, since they will require priveledged access to administer the systems. Group responsibilities will include:

• Setting up OSGeo systems at Telascience.
• Providing backup and recovery capabilities. A key feature we are offering projects is well administered systems to minimize downtime and other discontinuities.
• Installing software components (ie. Plone, Confluence, Trac) used for collaberation.
• Installing software for testing and demonstration (ie. our software and dependencies).
• Installing and managing authentication services (ie. LDAP).

This working group is going to need to document procedures, locations of things, and so forth quite carefully so that stuff doesn't get completely forgotten, and so that we aren't too limited to one person to fix things. This will require dicipline but will be important. This might happen in the public wiki (or possibly a private system administrators wiki?).

See also: SAC

Permissions Management

We will need a way of managing the permissions level of various OSGeo members. It is planned that an LDAP server will be used to handle the user database (a distinct list from those at CollabNet for now). But does this address how we delegate permissions to different people? How do we decide who has login permissions on test systems for instance, or who has update permissions in a given Plone instance?

Some categories of permissions we need to address:

• Some systems would only provide login access to the system administration working group. These systems we would hope could be very stable.
• Login on some systems, such as test systems would need to be very widely available, essentially to all OSGeo project developers for testing. Presumably normal developers would not require root access, but we could still assume these systems are likely to be subject to damage and need to be fairly easily recreated.
• We may also want "Project" systems, roughly owned by a single project with appropriate project staff having full (ie. root) permissions. Can we provide some sort of virtualization to offer roughly this to people? Perhaps "chrooted jails"? This might be the sort of place that projects would have automated scripts running to create nightly snapshots, re-create projects web pages or whatever.

See Also

• informal survey of what FLOSS foundations generally provide as services
• Incubation Committee
• Website Committee
• Public Geospatial Data Committee