Sugar Labs

Deployment Platform/1.1/Todo: Difference between revisions

Created page with "All 1.x minor releases will be based on deployment needs. Including taking decision what following features need to be implemented. == Documentation == * in-code documentation ..."
 
 
(21 intermediate revisions by the same user not shown)
Line 1: Line 1:
All 1.x minor releases will be based on deployment needs. Including taking decision what following features need to be implemented.
== New distro support ==


== Documentation ==
* <strike>Support Ubuntu [Server] in Mace.</strike>
 
== sugar-server-blacklist ==
 
[[Sugar_Server_Kit/sugar-server-blacklist|New]] SSK component.
 
* <strike>package blacklists for content filtering in SSK repo</strike>
* <strike>setup infra on jita.sugarlabs.org for regular updates for this package</strike>
* <strike>add blacklist provider to the Mace.</strike>


* in-code documentation for sugar-server and sugar-server-templates
== sugar-client ==


== Testing ==
[[Sugar_Server_Kit/sugar-client|New]] SSK component.


* more system tests of SSK infra using sugaroid to cover various deployment workflows
* <strike>handle datastore backup/restore</strike>
* using sugaroid bots, stress test prosody to compare with ejabberd
* <strike>handle package upgrades from school server for deployment specific updates (from separate repositories)</strike>


== More sugar-server-base templates ==
== Documentation ==


Depending on will mace configuration be used in Sugar Server based deployments or not, implement configuration for all needed services:
* <strike>in-code documentation for sugar-server and sugar-server-templates</strike>, not completed, will be continued while working on 1.2
* Content filter. Options are: Dans Guardian (MinD fork?), SquidCache, OpenDNS
* Monitoring support. If connectivity is good, then no questions, there are bunch of ready-to-use solutions like Munin, Nagious, etc. The problematic usecase is having servers that are mostly or entirely offline. The way might be collecting data on school servers and pass them to the mothership somehow via sneakernet. Options: run http://collectd.org/ daemons on school servers and provide useful uploading method


== Initial Smart Objects support ==
== Testing ==


[[Features/Smart_Objects]]
* <strike>more system tests of SSK infra using sugaroid to cover various deployment workflows</strike>, not fully completed, moved to 1.2 TODO and looking for SSK usage in the field;
* <strike>using sugaroid bots, stress test prosody to compare with ejabberd</strike>, not completed, moved to 1.2 TODO;
* <strike>the basis for regression tests to keep 1.x branch w/o regressions</strike> all SSK components have an initial set (the process is ongoing) of unit tests that will let keep the system out of regressions.


Many things to think about at first before any implementation...
== New templates ==


== Mothership ==
* <strike>squidGuard</strike>
* <strike>munin-node</strike>


* Interaction with motherships
== Deployment ==
* (?) Initial sugar-mothership implementation, only regarding to current sugar-server functionality


Need to collect more experience from XS deployments before any implementation...
* <strike>SSK based .py final solution</strike>, [[Sugar_Server_Kit/Solutions/Paraguay_Educa_Server|.py pilot program]].
Retrieved from "https://wiki.sugarlabs.org/go/Deployment_Platform/1.1/Todo"