Platform Team/Server Kit/Architecture

Intention

This project is an attempt to refocus the School Server paradigm from "only a School Server on a server at school" to "having tough and localized software components to use for a purpose". The core component, sugar-server, should just work after installing from packages if a school needs only basic functionality in an already set up environment. It works without close maintenance from skilled personal. But if a school or deployment needs more functionality, and they have spare servers, the additional components might be used to fulfill local needs.

• Be a community project within Sugar Labs to keep core development processes in one place;
• It is not about configuring and supporting the whole server at school from scratch, but about having a set of tough, local, doing its job well modules that might be included/excluded in downstream solutions;
• Friendly support of customization on purpose in downstream products:
  • Modularizing, when components might be included on purpose to fulfill local needs,
  • Not patching in downstream, but supplementing the upstream, e.g., install upstream packages and just add new packages with local customization or overrides (but not overriding installed files to let PMS work smoothly) of upstream,
  • Provide useful API for components;
• Be GNU/Linux distribution agnostic, different deployments might decide to use different GNU/Linux distributions.
• It is not only about supporting XO laptops, but about any Sugar based environments;
• Support up to 1000 students per server.

Functionality model

This is all about how improved functionality of servers at schools might look, at least, Sugar Server Kit is being designed and implemented in this direction. Sugar Server Kit is not intended to cover all the components described here. It is just the global picture from a Sugar Server Kit point of view.

Two pure models might describe Sugar Server Kit design, the final model might be an intermediate variant of them.

Black box model

The model where the server at school is entirely dependent on Sugar Server Kit design decisions. There are two types of machines:

• servers at schools under Sugar Server Kit control
• optional mothership(s) to control school servers

The key points:

• Functionality of such servers is simple, only basic services. (Complex, thus not trivial for maintenance, services are on the mothership, where skilled personal can support them effectively.)
• The rest of school server functionality (which is not simple) is configured automatically.
• Interaction only happens via these flows, via Internet if connectivity is good, and via sneakernet otherwise:
  1. Incoming system updates flow (also, the way to trigger some configuration changes). This should be rare and a batch process.
  2. Incoming data flow for sugar related stuff like leases, activities, or content.
  3. Outgoing data flow to monitor servers.

One package model

The model with minimal Sugar Server Kit design influence:

• existing and configured out of Sugar Server Kit servers at schools
• the remaining environment that Sugar Server Kit is not aware of

The key points:

• Servers at schools are supported out of Sugar Server Kit.
• Admins install the sugar-server package from upstream binary repositories, and just launch it.
• sugar-server starts to serve all sugar boxes around, providing only basic sugar specific functionality.
• sugar-server doesn't break the system configuration (it touches nothing).

Distribution model

How Sugar Server Kit might be reused from downstream, excluding the most obvious way, download its sources.

Core packages

Sugar Server Kit is designed to avoid patching its sources in downstream. Reusing upstream binary packages as-is from repositories on http://download.sugarlabs.org is how Sugar Server Kit is being designed. Downstream might create new packages, that don't have file collisions with upstream packages, to have tweaks for local environment. It is being accomplished by:

• sugar-server project has services formed as plugins, from downstream packages. Such services might be:
  • enabled/disabled
  • added new services, e.g., variants of existing services that are highly tuned for local needs
• mace does not create any final configuration level logic and might be used to process any downstream configuration for services that it supports.

Core packages are per-component and might be reused as-is in downstream, in a way that is most practical for them.

Full cycle solution

Besides just having binary packages, it should be possible to build downstream packages and the final OS images on http://packages.sugarlabs.org by using only its web UI. The resulting files will be accessible for download from http://download.sugarlabs.org. It is an Open Build Service based service to build packages and images for rpm and deb based GNU/Linux distributions.

Deployment model

It is an entirely downstream decision as to how to deploy Sugar Server Kit based solutions.

Development model

Having a decent testing infrastructure is the major intention for Sugar Server Kit components. Every component needs to have, at least, unit tests for its internals. Components like Sugar_Server_Kit/sugar-server have also integration tests to cover integration issues for its parts.

Except component specific tests, it is important to have system integration testing when all components are being tested in collaboration. In that case, the sugaroid component, sugar client bot, will help.

The reliable testing environment should help with avoiding regressions while following Sugar Server Kit statement of purpose for releases.

Components

There are several Sugar Server Kit project components:

• sugar-server provides basic sugar specific services,
• sugar-server-templates provides configuration templates that might be reused in downstream solution,
• mace process configuration sources, e.g., from sugar-server-templates,

The only relationship between them are:

• sugar-server-templates contain basic configuration for sugar-servers.
• sugar-server-templates makes sense only after processing its content by mace.

These are building blocks for the final solutions in downstream deployments. Components are optional, meaning that

• sugar-server might be used in the singular manner; it doesn't need any special (outside of sugar-server) configuration, and can be started even from its sources directory;
• sugar-server-templates might be used in the singular manner (but obviously with the mace) to configure only non Sugar services;
• mace might be used in the singular manner to configure any services.