On 22/11/11 13:06, Stefan Werden wrote:
> Carsten, David and Martin,
>
> first thank you very much for this postive feedback. I like to continue our
> discussion in this forum. I hope you got the last email where i showed we can
> offer any kind of support for the mer infrastructure and keeping of cause
> everything as open as today. This is how it should be:
>
> My question is: Are you fine and how can we start practicly. I feel executing 
> is
> the most important. Any ideas about that? Or should we summarize in this forum
> first?

This is great Stefan - so first of all: thank you for your support!

> So the blades are running and connected and can be configured etc. The bigger
> iron needs to be defined and I need to buy it first. So curently I can provide
> 20-24 cores, echo 2 cores one hardware. So I am ready now :)

OK - if you'd like to send me a private email with connection details I'll get
onto that at once. I'll drop you a pgp mail in case you'd like to encrypt.

> I think forum services, wiki etc. we can also start directly.

Yep and I'll find a way to document our internal setup in a way that doesn't
compromise security.

> Anyway, I like to synchonize and make a roadmap.
>
> What do you think?

So ... towards a roadmap and pulling some text from recent off-list emails :

I think there are 3 areas that the Mer project can aim to deliver:

1. Web and community:
* Infrastructural services : DNS, LDAP, ssh, sysadmin wiki, backup, monitoring 
etc
* Basic web services : wiki, bugzillas (a few), web, mailing lists
* Code hosting : gerrit
* Download

The basics are pretty much setup but needs work on things like resilience and
backup. These services will also be offered to 'incubated' projects like
nemomobile.org.

2. Core QA and Release build service:
* Mer Code building : OBS (this is where the big machines come in - 3+ large RAM
physical hosts)
* QA Automation : BOSS
* Reference image building : IMG

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 anticipate distributing these services amongst
multiple hosted facilities.

3. 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
* QA Automation : BOSS
* Image building : IMG
Again the focus is on RAM and physical hosts - lots of them!

>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 (not sure if you're aware but I ran meego.com infra with Niels and 
co)

* we have approached OSUOSL and RackSpace for sponsored hosting

As we expand we should keep in mind that there are many aspects of our project
that can be run across distributed physical hosts without issue - and there are
other areas where I think consolidation may make a big difference. We need to be
aware of how long donations are for too - that way we can plan to migrate if
time runs out.

I would like to find a way to make effective use of contributions too - eg allow
donations of or towards hardware (especially RAM upgrades!) whilst ensuring
those donations are properly accounted.

Lots more too I'm sure.... but as you say ... lets get started with it.

David

-- 
"Don't worry, you'll be fine; I saw it work in a cartoon once..."


Reply via email to