Sugar Labs

Platform Team/Server Kit/Architecture: Difference between revisions

← Older editNewer edit →
No edit summary
rename sugar-server-base to sugar-server-templates
Line 60: Line 60:
** enabled/disabled
** enabled/disabled
** added new services, e.g., variants of existing services that are highly tuned for local needs
** added new services, e.g., variants of existing services that are highly tuned for local needs
* [[The Server/Mace|mace]] tool that processes the configuration from sugar-server-base packages is designed to have several configuration sources for the same service, so downstream configuration packages might change/hide/complement upstream configuration.
* [[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.
Line 77: Line 77:


* [[The_Server/sugar-server|sugar-server]] provides basic sugar specific services,
* [[The_Server/sugar-server|sugar-server]] provides basic sugar specific services,
* [[The_Server/sugar-server-base|sugar-server-base]] provides configuration only for basic external services that need to be installed and configured on bare servers at school,
* [[The_Server/sugar-server-templates|sugar-server-templates]] provides configuration templates that might be reused in downstream solution,
* [[The_Server/Mace|mace]] process configuration sources, e.g., from sugar-server-base.
* [[The_Server/Mace|mace]] process configuration sources, e.g., from sugar-server-templates,


The only relationship between them are:
The only relationship between them are:


* sugar-server might be configured from sugar-server-base.
* sugar-server-templates contain basic configuration for sugar-servers.
* sugar-server-base makes sense only after processing its content by mace.
* 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
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 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-base might be used in the singular manner (but obviously with the mace) to configure only non Sugar services;
* 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.
* mace might be used in the singular manner to configure any services.
Retrieved from "https://wiki.sugarlabs.org/go/Platform_Team/Server_Kit/Architecture"