[Sugar-devel] [IAEP] ASLO updates

[Aleksey Lim]

On Thu, Oct 15, 2009 at 02:42:15AM -0400, Bernie Innocenti wrote:
> [cc += dfarning, alsroot, systems@]
> 
> El Wed, 14-10-2009 a las 17:47 -0700, Josh Williams escribió:
> > I've made some bug fixes to the new ASLO design, I've tested it lightly 
> > and it seems to work in all major browsers (even ie6). If you have a few 
> > moments, please test it out (download/upload activities, browse around) 
> > and let me know if you see any display bugs or major usability issues.
> > 
> > http://activities-devel.sugarlabs.org/en-US/sugar/
> 
> All links to activity bundles appear to be broken :-(
> For example:
> 
>  http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail
> 
> I'm not sure how to fix it, but I can imagine that it may be related
> with moving the activity bundles from their old location
> (/srv/www-sugarlabs/activities/files) to the upload directory
> (/srv/upload/activities/) done by Dfarning in order to enable
> Mirrorbrain.
> 
> Earlier today, alsroot asked me to fix some permission issues that would
> prevent aslo from writing new activities in the new location.

Thats intended to be so, activities-devel is just mysql copy of
activities, I thought, it shouldn't affect activities-devel testing(but
you can create new activity/version and it should be downloaded).

> also noticing that there's still a copy of the activities in the old
> location, and it is also bigger by 40MB!

Thats because /srv/www-sugarlabs/activities/files contains some tmp
directory, it shouldn't affect .xo downloading.

> /me is very confused :-/
> 
> Could anyone who was involved please write a short description of what
> was changed exactly? I'm only trying to reconstruct the current
> situation, not looking for a scapegoat.

We just tried to utilize AMO feature when it lets user download
public .xos from mirror sources and from files/ for other cases.
Recently all .xo were downloaded from files/(even after creating symlink
in /upload to files/).. and it was done from several attempts.

For now we have two independent sources for .xo downloads:
* /srv/www-sugarlabs/activities/files for not public activities
  and for 30min age public activities 
* mirrored /upload/activities for all public activities,
  after making new .xo public, ASLO uploads it to /upload/activities

> Hmm... well, perhaps we can learn something from this accident:
> 
> The classic way to avoid the "too many cooks" syndrome would be to
> appoint a single official maintainer and make all the change requests go
> through him. However, I feel this "solution" would create lots of
> critical roles and ultimately defeat our ongoing attempts to
> decentralize system administration.
> 
> Instead, we shall establish simple procedures to improve sysadmin
> coordination and communication. For example:
> 
> 1) commit configuration changes in git along with a short description
>    of what was done and why. We already have repositories for /etc and
>    also and we could create more repos as needed;

Yeah, for now, ASLO configs are stored only in
~activities/site/app/config

> 2) write a short report for systems@ when we make substantial changes
>    to a service;
> 
> 3) write or update the wiki documentation for important sysadm
>    procedures such as installing a new instance of a service
> 
> Use your common sense to decide what needs to be documented and how much
> detail is needed. At all costs, we want to avoid putting too much
> bureaucratic burden on volunteers because it's the most effective way to
> make them look for something more exciting to do.
> 
> We could save time by coalescing steps (1) and (2): all we need to do is
> enabling a post-commit hook in the repositories that would send patches
> to systems-logs@ . We need to be extra careful not to expose passwords
> in this way. Any volunteers to write and test this procedure?

Well, we don't need such ASLO specific administration 24x7, most of time
it could be just regular file-permissions/apache/etc administration.

-- 
Aleksey