Difference between revisions of "Deployment Platform/1.0/Todo"

From Sugar Labs
Jump to navigation Jump to search
 
(28 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== 1.0 ==
+
Initial Sugar Server release that is not intended to be used as-is in deployments. It is about having stable code base and infra to fulfil deployment needs in further 1.x releases.
  
=== <strike>Initial coding of core components</strike> ===
+
== Initial coding of core components ==
  
* sugar-server
+
* <strike>sugar-server</strike>
* sugar-server-base
+
* <strike>sugar-server-base</strike>
* mace
+
* <strike>mace</strike>
  
 
Need to be polished though (see the rest of TODO).
 
Need to be polished though (see the rest of TODO).
  
=== Patch OBS ===
+
== Testing ==
  
* produce binary packages with sugar-server, mace and sugar-server-base for Fedora-11<br>[[User:Alsroot|alsroot]] 19:46, 9 June 2011 (EDT)
+
* <strike>sugar-server unit tests</strike>, initial work done the rest is in permanent process
* (?) Create images on OBS for Fedora
+
* <strike>mace unit tests</strike>, initial work done the rest is in permanent process
 +
* <strike>sugaroid, library and application that represent regular sugar client behaviour</strike>
 +
* <strike>sugar-server integration tests using sugaroid library</strike>, initial work done the rest is in permanent process
 +
* <strike>system tests of sugar-server + sugar-server-base infra with reproducing usual and stress behaviour of sugar client using sugaroids instances (up to 1K)</strike> sounds like more deployment related task, thus moved to 1.x releases
  
=== Prosody ===
+
== Patch OBS ==
  
* improve mod_sugar_roaster plugin to share the same memory structure of sugar roaster among all buddies
+
* <strike>produce binary packages with sugar-server, mace and sugar-server-base for Fedora-14</strike>
* stress test it, up to 1K users
+
* <strike>while most of packages come from initial distro release, monitor for updates for some of package, e.g., xulrunner when hulahop needs to be rebuilt on any new xulrunner update</strike> all packages on obs are based on initial distro releases, hulahop/sugar were patched to not fail on every minor update
 +
* <strike>announce packages.sl.o, not only for Sugar Server usage but also for sweets/sdk</strike> will be announced with sweets
  
Sugar code is here, http://git.sugarlabs.org/server/prosody
+
== Prosody ==
  
=== Content filter ===
+
* <strike>improve mod_sugar_roaster plugin to share the same memory structure of sugar roaster among all buddies</strike>
 +
* <strike>using sugaroid bots, stress test prosody to compare with ejabberd</strike> not ready, moved to 1.x
  
Need to decide what content filter software configuration will be included to sugar-server-base.
+
Sugar code is here, http://git.sugarlabs.org/server/prosody-sugar
  
Options are:
+
== Documentation ==
  
* Dans Guardian (MinD fork, since it provide proxy-less mode that might be useful if some deployment don't need proxy)
+
<strike>Initial documentation efforts on the wiki.</strike>
* SquidCache
 
* OpenDNS
 
* ?
 
  
Thoughts:
+
== Tech demo ==
  
* Dans Guardian's site declares that it is faster then SquidCache but publication date is too old
+
<strike>Test case:
* Dans Guardian's MinD for is promising option, it support proxy-less mode and has recent activity (in comparing with Dans Guardian)
 
* OpenDNS way might be useful, i.e., having such server on the mothership and point all school servers' dns there. but can't find (?) FOSS project with such functionality and opendns.com is pure commercial organisation with ugly stuff like forwarding failed request to is site with ads and it can change the rules at any time.
 
  
=== Monitoring support ===
+
* on unlocked XO, plug usb stick with demo server image, flash and booth
 +
* on locked XO, inject lease demo keys from a usb stick and boot
 +
* locked XO should be fine with:
 +
** activate on boot on unlocked XO
 +
** register user
 +
** do journal backup
 +
** restore journal
 +
** connect to jabber
  
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.
+
Demo server XO image will be composed by adding {{Code|downstream-server-demo}} package (and all its deps) during the regular XO image building process.</strike>
 
 
Thoughts:
 
 
 
* run http://collectd.org/ daemons on school servers and provide useful uploading method
 
 
 
=== Initial Smart Objects support ===
 
 
 
[[Features/Smart_Objects]]
 
 
 
=== Mothership ===
 
 
 
* Interaction with motherships
 
* (?) Initial sugar-mothership implementation, only regarding to current sugar-server functionality
 

Latest revision as of 16:28, 8 October 2012

Initial Sugar Server release that is not intended to be used as-is in deployments. It is about having stable code base and infra to fulfil deployment needs in further 1.x releases.

Initial coding of core components

  • sugar-server
  • sugar-server-base
  • mace

Need to be polished though (see the rest of TODO).

Testing

  • sugar-server unit tests, initial work done the rest is in permanent process
  • mace unit tests, initial work done the rest is in permanent process
  • sugaroid, library and application that represent regular sugar client behaviour
  • sugar-server integration tests using sugaroid library, initial work done the rest is in permanent process
  • system tests of sugar-server + sugar-server-base infra with reproducing usual and stress behaviour of sugar client using sugaroids instances (up to 1K) sounds like more deployment related task, thus moved to 1.x releases

Patch OBS

  • produce binary packages with sugar-server, mace and sugar-server-base for Fedora-14
  • while most of packages come from initial distro release, monitor for updates for some of package, e.g., xulrunner when hulahop needs to be rebuilt on any new xulrunner update all packages on obs are based on initial distro releases, hulahop/sugar were patched to not fail on every minor update
  • announce packages.sl.o, not only for Sugar Server usage but also for sweets/sdk will be announced with sweets

Prosody

  • improve mod_sugar_roaster plugin to share the same memory structure of sugar roaster among all buddies
  • using sugaroid bots, stress test prosody to compare with ejabberd not ready, moved to 1.x

Sugar code is here, http://git.sugarlabs.org/server/prosody-sugar

Documentation

Initial documentation efforts on the wiki.

Tech demo

Test case:

  • on unlocked XO, plug usb stick with demo server image, flash and booth
  • on locked XO, inject lease demo keys from a usb stick and boot
  • locked XO should be fine with:
    • activate on boot on unlocked XO
    • register user
    • do journal backup
    • restore journal
    • connect to jabber

Demo server XO image will be composed by adding downstream-server-demo package (and all its deps) during the regular XO image building process.