8,288
edits
Changes
Jump to navigation
Jump to search
Line 8:
Line 8: − + − + − The only relationship between them are:+ − + Line 20:
Line 20: − + Line 29:
Line 29: − + − + − + Line 40:
Line 40: − + − + − + − + − + − + − + − + − + − + − + Line 71:
Line 71: − + Line 77:
Line 77: − + − + − + − + Line 96:
Line 96: − + − + − +
Platform Team/Server Kit/Architecture (view source)
Revision as of 15:12, 23 November 2011
, 15:12, 23 November 2011no edit summary
* [[Sugar_Server_Kit/sugar-server|sugar-server]] provides basic sugar specific services,
* [[Sugar_Server_Kit/sugar-server|sugar-server]] provides basic sugar specific services,
* [[Sugar_Server_Kit/sugar-server-templates|sugar-server-templates]] provides configuration templates that might be reused in downstream solution,
* [[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]] process configuration sources, e.g., from sugar-server-templates,
* [[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 contain basic configuration for sugar-servers.
* sugar-server-templates makes sense only after processing its content by mace.
* sugar-server-templates make sense only after its content is processed by mace.
These are building blocks for the final solutions in downstream deployments.
These are building blocks for the final solutions in downstream deployments.
== Server functionality models ==
== Server functionality models ==
Sugar Server Kit components are being designed to accomplish different functionality models, when the particular model might include only limited number of ingredients. The following models might describe Sugar Server Kit design, the final model might be an intermediate variant of them.
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 ===
=== Only sugar-server package ===
* Existing and configured out of Sugar Server Kit servers at schools.
* Existing and configured out of Sugar Server Kit servers at schools.
* School admins need to take care about setting up sugar-server specific [[Sugar_Server_Kit/sugar-server#Services|requirement configuration]] for external environment.
* 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 upstream binary repository, and just launch it.
* 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 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).
* sugar-server doesn't break the system configuration (it touches nothing).
The maintaining process is the same as for any other service launched on a server.
The maintenance process is the same as for any other service launched on a server.
=== Dumb school servers ===
=== 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:
* Dumb servers at schools under Sugar Server Kit control. The explicit intention is to minimize maintaining intervention as much as possible.
* Dumb servers at schools under Sugar Server Kit control. The explicit intention is to minimize maintenance intervention as much as possible.
* The Mothership to minimal control of school servers and handling the rest of functionality that people at schools need.
* 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 school servers is simple, only basic services.
* Functionality of school servers is simple, only basic services.
* Complex, thus not trivial for maintenance, services are on the mothership and singular, i.e., to minimize maintaining costs and let the minimal number of skilled personal support them effectively.
* Complex, thus non-trivial for maintenance, services are on the mothership and singular, i.e., to minimize maintenance costs and let the minimal number of skilled personal support them effectively.
* A set of school server's services tends to be constant, at least it doesn't require regular intervention to add/remove services.
* 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 serves have exactly the same set of services.
* All school servers have exactly the same set of services.
This functionality model involves Mace and sugar-server-templates components. The entirely content of school servers is:
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:
* a set of packages, including the main one that contains
** all services as dependencies,
** all services as dependencies,
** upstream Mace configuration as sugar-server-templates dependency,
** upstream Mace configuration as a sugar-server-templates dependency,
** downstream Mace configuration;
** 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];
* 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.
* pure data, like leases and content black lists, to fetch as-is from the Mothership.
After installing the main package, it will provide possibility to fetch pure data from the Mothersip, and finally running Mace to complete school server setup.
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 maintaining process will be:
The maintenance process will be as follows:
* sugar-server-templates provides unattended packages update on school servers, packages to update come from:
* sugar-server-templates provide unattended packages updates on school servers; packages to update come from
** GNU/Linux official repositories with security updates,
** 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 appeared updates should not break already deployed systems;
** 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.;
* 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.
* 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 ===
=== Highly maintained school servers ===
Servers at schools might be not only simple like in the previous model. They might contain complex services like content management systems. This usecase might require more regular maintaining scenarios, e.g., using configuration tools like Puppet or CFEngine, having more detailed monitoring, etc.
Servers at schools might not be so simple as in the previous model. They might contain complex services like content management systems. This usecase 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.
It seems that the only useful Sugar Server Kit component here is the sugar-server.
== Client functionality models ==
== Client functionality models ==
There is only one Sugar Server Kit component to work on a client side, [[Sugar_Server_Kit/sugar-client|sugar-client]] the 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]].
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]].
== Distribution model ==
== 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.
== Development model ==
== 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|sugar-server]] have also integration tests to cover integration issues for its parts.
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.
Except component specific tests, it is important to have system integration testing when all components are being tested in collaboration. In that case, the [[Platform_Team/Sugar_Unit|sugar-unit]] component, sugar client bot, will help.
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 [[Platform_Team/Sugar_Unit|sugar-unit]] component, sugar client bot, will help.
The reliable testing environment should help with avoiding regressions while following [[Sugar Server Kit]] [[Sugar_Server_Kit/Release plan|statement of purpose]] for releases.
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.