Revision as of 00:05, 30 November 2011

The Mer and Nemo projects rely quite a lot on the MeeGo community OBS and the infrastructure there - but that will be going away "soon".

Overview

The Mer project needs to provide 3 areas of service for the Mer Core and any 'incubated' community projects such as Nemo and others.

Web and community

Basic web services for Mer, Nemo and maybe others (1 VM per service per project, possibly a DB VM)
- Wikis
- Bugzillas
- Web
- Mailing lists
Code hosting : gerrit (1 medium VM)
Download: (1 medium VM with disk space and bandwidth)
Infrastructural services : DNS, LDAP, ssh, sysadmin wiki, backup, monitoring etc (~6 small VMs)

The services above would ideally be hosted across 2 physical hosts with good interconnection for resilience.

Core QA and Release build service

Mer Code building : OBS (heavy - 3+ large RAM physical hosts)
QA Automation : BOSS (1 VM)
Reference image building : IMG (1 physical host)

We anticipate this needing 3 or 4 physical hosts (depending on spec).

Large amounts of RAM and virtualisation are the most important factor here. SSSE3 would be nice too. (We'd like to experiment with overcommitted tmpfs and swap on SSD as a way to make best use of RAM.)

Community OBS

We also would like to provide a community build service to fill the same needs as the MeeGo Community OBS did:

Community developer code building for Mer, Nemo, Plasma and other 'incubated' projects : OBS (heavy - 3+ large RAM physical hosts - build.pub.meego.com has 8 at the moment)
QA Automation : BOSS (1 VM)
Image building : IMG (1 or more physical host)

Again the focus is on RAM and physical hosts.

Supporting Mer

Our intended governance model is here: Governance draft

As we become more established the advisory board would handle resource planning and funding. We have not formulated any sponsorship arrangements but would expect to put sponsored-by logos in prominent positions. We would prefer to fully disclose sponsorship arrangements but the AB will discuss this if the need arises.

Contribution Commitments

If you'd like to contribute to the Mer infrastructure then we need to know how long we can rely on services being avaiable. We ask that you make an estimate of how long you anticipate providing the service initially (and realistically a year is a sensible minimum term); if you are going to cease to provide the service to the project, we ask that you please let us know 3 months in advance

Current Deployment

From a sysadmin/deployment point-of-view we're keeping security fairly tight and prefer to run on dedicated hardware with very limited root access.

So where are we at the moment? :

Carsten and I have bought 3 physical hosts with 24GB RAM which we've almost completed setting up. These now host the QA/Release OBS and the web and infrastructure services; they can support vpn connections to additional phosts. They're pretty much at full capacity
the MeeGo community OBS provides 8x 64GB/16cpu workers and a 64GB/16cpu api/web/scheduler - these are already seeing heavy utilisation and provide an indicative target for a community service
our infrastructure is almost totally virtualised to permit easy migration and we have rapid-VM-deployment tools and good IT policy from the meego.com deployment
we have approached OSUOSL and RackSpace for sponsored hosting
Stefan Werden has made a concrete offer of some hardware

We have designed the infrastructure to be able to spread out services over multiple hosting environments. For example we plan to permit QA builds over multiple OBS installations in order to scale better as we support more targets.

VMs

Most of these VMs run on one very stretched phost!

Central Admin

We have internal admin VMs:

DNS, Audit, VM buildmaster, CA, generally a 'secure' host - not reachable from outside
puppetadm
mail, 2ndry DNS, internal wiki
ssh access
ldap internal accounts, ssh keys, VM access control
ldap external accounts
openvpn - provides a virtual management lan for LDAP, DNS, ntp etc

Services

shell - user homes
bz1
bz2
web
boss
gerrit
CI OBS fe (api/webui)
CI OBS be (scheduler, repo, src)
wiki

CI OBS workers : 2x 24Gb phosts

Missing

Community OBS
Community workers
Image building
Additional CI OBS Workers
Public wiki
Monitoring
Backup

Technology

We use:

OpenSuse 11.4 on the physical host (legacy from MeeGo infra - OBS workers have to use this so we use it everywhere for consistency. Good choice for customers as it offers supported variants and we like to support SuSE)
Debian Squeeze on VMs unless Suse is needed (our admins prefer Debian)
KVM virtualisation (we used Xen on meego.com and it was fine - KVM is supposed to have better I/O caching)

From a sysadmin PoV:

DCP - 'homegrown' mix of rsync and git to make a distributed etckeeper
Puppet for common file management (SSL keys, pam/ldap conf, resolv.conf, ntp, sshd ...)
LDAP for accounts
ssh via jump machine

Contributing Hardware

What are we looking for? Hopefully we can take any reasonable contribution and would suggest any of:

A large collection of physical hosts to use as the community build service
A small collection of physical hosts as QA/build/Image or other services
Individual physical hosts to use as remote workers or service hosts
Service support (eg drupal, email, nagios, puppet etc)
Data backup services
Mirrors (although this is not a critical issue)
Donations to OSUOSL or other hosting provider (subject to an agreement with them)

If you can help with any of this we would be extremely grateful.

Infrastructure Requirements

Revision as of 00:05, 30 November 2011

Contents