Platform Team/Server Kit/Architecture - Revision history

Alsroot: moved Sugar Server Kit/Architecture to Platform Team/Server Kit/Architecture: Move SSK to HSD

2012-03-21T09:48:38Z

moved Sugar Server Kit/Architecture to Platform Team/Server Kit/Architecture: Move SSK to HSD

← Older revision	Revision as of 05:48, 21 March 2012
(No difference)

FGrose at 00:57, 3 December 2011

2011-12-03T00:57:37Z

← Older revision		Revision as of 20:57, 2 December 2011
Line 50:		Line 50:

	* Functionality of school servers is simple, only basic services.		* Functionality of school servers is simple, only basic services.
	* 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~~.		* 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.		* 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.		* All school servers have exactly the same set of services.
Line 75:		Line 75:
	=== Highly maintained 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 ~~usecase~~ might require more regular maintenance scenarios, e.g., using configuration tools like Puppet or CFEngine, or 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 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.		It seems that the only useful Sugar Server Kit component here is the sugar-server.

Alsroot: /* Components */

2011-11-30T18:14:56Z

Components

← Older revision		Revision as of 14:14, 30 November 2011
Line 7:		Line 7:
	There are several major Sugar Server Kit project components that will be mentioned on this page:		There are several major Sugar Server Kit project components that will be mentioned on this page:

	* [[Sugar_Server_Kit/sugar-server\|sugar-server]] provides basic sugar specific services,		* [[Sugar_Server_Kit/sugar-server\|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_Kit/sugar-server-templates\|sugar-server-templates]] provide configuration templates that might be reused in a 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]] processes configuration sources, e.g., from sugar-server-templates,		* [[Sugar_Server_Kit/Mace\|mace]] processes configuration sources, e.g., from sugar-server-templates,

Alsroot at 17:52, 30 November 2011

2011-11-30T17:52:08Z

← Older revision		Revision as of 13:52, 30 November 2011
Line 98:		Line 98:
	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.		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 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.		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.

	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.		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.

FGrose at 20:12, 23 November 2011

2011-11-23T20:12:20Z

Show changes

Alsroot: /* Dumb school servers */

2011-11-23T12:46:57Z

Dumb school servers

← Older revision		Revision as of 08:46, 23 November 2011
Line 59:		Line 59:
	* 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 ~~Mace environment file and~~ pure data from the Mothersip, and finally running Mace to complete school server setup.		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.

	The maintaining process will be:		The maintaining process will be:
Line 67:		Line 67:
	** 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 appeared 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.
	* do occasional changes in the Mace environment file to reflect on global changes in deployment infrastructure.

	=== Highly maintained school servers ===		=== Highly maintained school servers ===

Alsroot at 21:36, 10 November 2011

2011-11-10T21:36:34Z

← Older revision		Revision as of 17:36, 10 November 2011
Line 99:		Line 99:
	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]] 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 [[~~Sugar_Server_Kit~~/~~sugaroid~~\|~~sugaroid~~]] component, sugar client bot, will help.		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.

	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 [[Sugar Server Kit]] [[Sugar_Server_Kit/Release plan\|statement of purpose]] for releases.

Alsroot: /* Client functionality models */

2011-11-06T16:52:53Z

Client functionality models

← Older revision		Revision as of 12:52, 6 November 2011
Line 78:		Line 78:
	== Client functionality models ==		== Client functionality models ==

	~~''TODO''~~		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]].

	== Distribution model ==		== Distribution model ==

Alsroot at 16:48, 6 November 2011

2011-11-06T16:48:25Z

@@ Line 2: / Line 2: @@
 {{:Sugar_Server_Kit/Architecture/The_purpose}}
 == Server functionality models ==
@@ Line 66: / Line 81: @@
 == 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:
@@ Line 79: / Line 90: @@
 Core packages are per-[[#Components|component]] and might be reused as-is in downstream, in a way that is most practical for them.
 == Deployment model ==
@@ Line 95: / Line 102: @@
 The reliable testing environment should help with avoiding regressions while following [[Sugar Server Kit]] [[Sugar_Server_Kit/Release plan|statement of purpose]] for releases.

Alsroot: /* Server functionality models */

2011-11-06T16:37:10Z

Server functionality models

← Older revision		Revision as of 12:37, 6 November 2011
Line 18:		Line 18:
	* 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.

	=== Dumb school servers ===		=== Dumb school servers ===
Line 43:		Line 45:

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

			The maintaining process will be:

			* sugar-server-templates provides unattended packages update 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 appeared 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;
			* do occasional changes in the Mace environment file to reflect on global changes in deployment infrastructure.

	=== Highly maintained school servers ===		=== Highly maintained school servers ===

	~~''TODO''~~		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.

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

	== Client functionality models ==		== Client functionality models ==

← Older revision		Revision as of 13:52, 30 November 2011
Line 98:		Line 98:
	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.		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 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.		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.

	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.		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.