Difference between revisions of "Platform Team/Server Kit/Architecture"

From Sugar Labs
Jump to navigation Jump to search
(Rename Sugar Serve to Sugar Server Kit)
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Intention ==
+
== The purpose ==
  
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.
+
{{:Sugar_Server_Kit/Architecture/The_purpose}}
  
* Be a community project within Sugar Labs to keep core development processes in one place;
+
== Components ==
* 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:
+
There are several major Sugar Server Kit project components that will be mentioned on this page:
** 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,
+
* [[Sugar_Server_Kit/sugar-server|sugar-server]] provides basic sugar specific services, such as:
** Provide useful API for components;
+
** OLPC anti-thief support,
* Be GNU/Linux distribution agnostic, different deployments might decide to use different GNU/Linux distributions.
+
** students registration,
* It is not only about supporting XO laptops, but about any Sugar based environments;
+
** share information about accessible services,
* Support up to 1000 students per server.
+
** Journal backup and restore.
 +
* [[Sugar_Server_Kit/sugar-server-templates|sugar-server-templates]] provide configuration templates that might be reused in a downstream solution,
 +
* [[Sugar_Server_Kit/Mace|mace]] processes configuration sources, e.g., from sugar-server-templates,
 +
 
 +
They all have the following in common:
 +
 
 +
* sugar-server-templates contain basic configuration for sugar-servers.
 +
* sugar-server-templates make sense only after its content is processed by mace.
 +
 
 +
These are building blocks for the final solutions in downstream deployments.
  
== Functionality model ==
+
== Server functionality models ==
  
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.
+
Sugar Server Kit components are being designed to accomplish different functionality models, where the particular model might include only a limited number of ingredients. The following models might describe a Sugar Server Kit design, the final model might be an intermediate variant of them.
  
Two pure models might describe Sugar Server Kit design, the final model might be an intermediate variant of them.
+
=== Only sugar-server package ===
  
=== Black box model ===
+
The model with minimal Sugar Server Kit design influence.
 +
 
 +
The key points:
 +
 
 +
* Existing and configured out of Sugar Server Kit servers at schools.
 +
* School admins need to take care about setting up a sugar-server specific [[Sugar_Server_Kit/sugar-server#Services|requirement configuration]] for the external environment.
 +
* School admins install the sugar-server package from an upstream binary repository, and just launch it.
 +
* sugar-server starts to serve all sugar boxes around, providing only [[#sugar-server|basic sugar specific]] functionality.
 +
* sugar-server doesn't break the system configuration (it touches nothing).
 +
 
 +
The maintenance process is the same as for any other service launched on a server.
 +
 
 +
=== Dumb school servers ===
  
 
The model where the server at school is entirely dependent on Sugar Server Kit design decisions. There are two types of machines:
 
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
+
* Dumb servers at schools under Sugar Server Kit control. The explicit intention is to minimize maintenance intervention as much as possible.
* optional mothership(s) to control school servers
+
* The Mothership, used to minimize control of school servers and handle any additional functionality that people in schools need.
  
 
The key points:
 
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.)
+
* Functionality of school servers is simple, only basic services.
* The rest of school server functionality (which is not simple) is configured automatically.
+
* Complex—thus, non-trivial for maintenance—services are on the mothership and singular, so to minimize maintenance costs and allow effective support with the minimum number of skilled personal.
* Interaction only happens via these flows, via Internet if connectivity is good, and via sneakernet otherwise:
+
* A set of school server's services tends to be constant, at least it doesn't require regular intervention to add/remove services.
*# Incoming system updates flow (also, the way to trigger some configuration changes). This should be rare and a batch process.
+
* All school servers have exactly the same set of services.
*# Incoming data flow for sugar related stuff like leases, activities, or content.
 
*# Outgoing data flow to monitor servers.
 
  
=== One package model ===
+
This functionality model involves Mace and sugar-server-templates components. The entire content of school servers is as follows:
  
The model with minimal Sugar Server Kit design influence:
+
* a set of packages, including the main one that contains
 +
** all services as dependencies,
 +
** upstream Mace configuration as a sugar-server-templates dependency,
 +
** downstream Mace configuration;
 +
* Mace environment file, e.g., the one from sugar-server-templates [http://git.sugarlabs.org/server/templates/blobs/master/etc/base.env.example examples];
 +
* pure data, like leases and content black lists, to fetch as-is from the Mothership.
  
* existing and configured out of Sugar Server Kit servers at schools
+
After installing the main package, it will provide the possibility to fetch pure data from the Mothersip, and finally run Mace to complete the school server setup.
* the remaining environment that Sugar Server Kit is not aware of
 
  
The key points:
+
The maintenance process will be as follows:
 +
 
 +
* sugar-server-templates provide unattended packages updates on school servers; packages to update come from
 +
** GNU/Linux official repositories with security updates,
 +
** Sugar Server Kit upstream repository that follows the [[Sugar_Server_Kit/Release_plan|Statement of purpose for releases]], i.e., declares that newly appearing updates should not break already deployed systems;
 +
* taking care that pure data on the Mothership is up-to-date, e.g., leases are properly created, content filtering blacklists are fresh, etc.;
 +
* do occasional changes in the main school server package to add new services or tune downstream Mace configuration and upload it to the repository that will be used for unattended updates on school servers.
 +
 
 +
=== Highly maintained school servers ===
 +
 
 +
Servers at schools might not be so simple as in the previous model. They might contain complex services like content management systems. This use case might require more regular maintenance scenarios, e.g., using configuration tools like Puppet or CFEngine, or having more detailed monitoring, etc.
  
* Servers at schools are supported out of Sugar Server Kit.
+
It seems that the only useful Sugar Server Kit component here is the sugar-server.
* 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 [[#sugar-server|basic sugar specific]] functionality.
 
* sugar-server doesn't break the system configuration (it touches nothing).
 
  
== Distribution model ==
+
== Client functionality models ==
  
How Sugar Server Kit might be reused from downstream, excluding the most obvious way, download its sources.
+
There is only one Sugar Server Kit component to work on the client side, [[Sugar_Server_Kit/sugar-client|sugar-client]] that implements [[Sugar_Server_Kit/Client_API|Client API]]. Sugar-client works directly with sugar-server using its public [[Sugar_Server_Kit/sugar-server#Services|API]].
  
=== Core packages ===
+
== Distribution model ==
  
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 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, which must not have file collisions with upstream packages, in order to have tweaks for the local environment. This is accomplished by the following:
  
* sugar-server project has services formed as plugins, from downstream packages. Such services might be:
+
* sugar-server project has services formed as plugins, from downstream packages. Such services might be
 
** enabled/disabled
 
** enabled/disabled
** added new services, e.g., variants of existing services that are highly tuned for local needs
+
** newly added services, e.g., variants of existing services that are highly tuned for local needs
 
* [[The Server/Mace|mace]] does not create any final configuration level logic and might be used to process any downstream configuration for services that it supports.
 
* [[The Server/Mace|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-[[#Components|component]] and might be reused as-is in downstream, in a way that is most practical for them.
 
Core packages are per-[[#Components|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 [https://build.opensuse.org/ Open Build Service] based service to build packages and images for rpm and deb based GNU/Linux distributions.
 
  
 
== Deployment model ==
 
== Deployment model ==
Line 72: Line 98:
 
It is an entirely downstream decision as to how to deploy Sugar Server Kit based solutions.
 
It is an entirely downstream decision as to how to deploy Sugar Server Kit based solutions.
  
== Components ==
+
== Development model ==
 
 
There are several Sugar Server Kit project components:
 
  
* [[Sugar_Server_Kit/sugar-server|sugar-server]] provides basic sugar specific services,
+
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|sugar-server]] also have integration tests to cover integration issues for its parts.
* [[Sugar_Server_Kit/sugar-server-templates|sugar-server-templates]] provides configuration templates that might be reused in downstream solution,
 
* [[Sugar_Server_Kit/Mace|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
+
Except for component specific tests, it is important to have system integration testing when all components are being tested in collaboration. In that case, the [[Sugar_Server_Kit/sugar-unit|sugar-unit]] component, sugar client bot, will help.
  
* 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;
+
The reliable testing environment should help with avoiding regressions while following the [[Sugar Server Kit]] [[Sugar_Server_Kit/Release plan|statement of purpose]] for releases.
* 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.
 

Latest revision as of 05:48, 21 March 2012

The purpose

The Sugar Server Kit initiative is an attempt to achieve the following major goals:

  • Provide a split between the community level project (Sugar Server Kit) and any number of downstream solutions based on the community project. This should stimulate the downstream community to contribute to this upstream community project, facilitating reuse of its experience in all other downstreams;
  • Treat the community project as a collection of useful tools, created and supported by community contributors, that might be composed into a final deployment solution on purpose, i.e., Sugar Server Kit is not an OS or a final solution, but rather a bunch of tools that might be launched on any major GNU/Linux distribution at the deployment level. And because some of these tools might be implemented in several ways, it should make the acceptance process of new features by upstream more flexible;
  • The whole system should be as reliable as possible. Thus, the community project will provide a decent testing environment (several levels of automatic and human driven tests at the top level), which might be used not only for Sugar Server Kit itself, but for deployment solutions as well;
  • 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.

Components

There are several major Sugar Server Kit project components that will be mentioned on this page:

  • sugar-server provides basic sugar specific services, such as:
    • OLPC anti-thief support,
    • students registration,
    • share information about accessible services,
    • Journal backup and restore.
  • sugar-server-templates provide configuration templates that might be reused in a downstream solution,
  • mace processes configuration sources, e.g., from sugar-server-templates,

They all have the following in common:

  • sugar-server-templates contain basic configuration for sugar-servers.
  • sugar-server-templates make sense only after its content is processed by mace.

These are building blocks for the final solutions in downstream deployments.

Server functionality models

Sugar Server Kit components are being designed to accomplish different functionality models, where the particular model might include only a limited number of ingredients. The following models might describe a Sugar Server Kit design, the final model might be an intermediate variant of them.

Only sugar-server package

The model with minimal Sugar Server Kit design influence.

The key points:

  • Existing and configured out of Sugar Server Kit servers at schools.
  • School admins need to take care about setting up a sugar-server specific requirement configuration for the external environment.
  • School admins install the sugar-server package from an upstream binary repository, 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).

The maintenance process is the same as for any other service launched on a server.

Dumb school servers

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

  • Dumb servers at schools under Sugar Server Kit control. The explicit intention is to minimize maintenance intervention as much as possible.
  • The Mothership, used to minimize control of school servers and handle any additional functionality that people in schools need.

The key points:

  • Functionality of school servers is simple, only basic services.
  • Complex—thus, non-trivial for maintenance—services are on the mothership and singular, so to minimize maintenance costs and allow effective support with the minimum number of skilled personal.
  • A set of school server's services tends to be constant, at least it doesn't require regular intervention to add/remove services.
  • All school servers have exactly the same set of services.

This functionality model involves Mace and sugar-server-templates components. The entire content of school servers is as follows:

  • a set of packages, including the main one that contains
    • all services as dependencies,
    • upstream Mace configuration as a sugar-server-templates dependency,
    • downstream Mace configuration;
  • Mace environment file, e.g., the one from sugar-server-templates examples;
  • pure data, like leases and content black lists, to fetch as-is from the Mothership.

After installing the main package, it will provide the possibility to fetch pure data from the Mothersip, and finally run Mace to complete the school server setup.

The maintenance process will be as follows:

  • sugar-server-templates provide unattended packages updates on school servers; packages to update come from
    • GNU/Linux official repositories with security updates,
    • Sugar Server Kit upstream repository that follows the Statement of purpose for releases, i.e., declares that newly appearing updates should not break already deployed systems;
  • taking care that pure data on the Mothership is up-to-date, e.g., leases are properly created, content filtering blacklists are fresh, etc.;
  • do occasional changes in the main school server package to add new services or tune downstream Mace configuration and upload it to the repository that will be used for unattended updates on school servers.

Highly maintained school servers

Servers at schools might not be so simple as in the previous model. They might contain complex services like content management systems. This use case might require more regular maintenance scenarios, e.g., using configuration tools like Puppet or CFEngine, or having more detailed monitoring, etc.

It seems that the only useful Sugar Server Kit component here is the sugar-server.

Client functionality models

There is only one Sugar Server Kit component to work on the client side, sugar-client that implements Client API. Sugar-client works directly with sugar-server using its public API.

Distribution model

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, which must not have file collisions with upstream packages, in order to have tweaks for the local environment. This is accomplished by the following:

  • sugar-server project has services formed as plugins, from downstream packages. Such services might be
    • enabled/disabled
    • newly added 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.

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 also have integration tests to cover integration issues for its parts.

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

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