[IAEP] [Systems] ASLO updates

[Aleksey Lim]

On Thu, Oct 15, 2009 at 07:34:50AM +0000, Aleksey Lim wrote:
> 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

hmm.. but what about passwords in ASLO configs

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

not sure, ASLO configs could be not obvious for others, so we need
explanation in email anyway.

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

Maybe just reuse issue tracker, I mean it could be a good way from
decentralization pov and all interested people can subscribe to
bugs.sl.o email notifications. So all administration related tasks(not
only ASLO) could be requested on bugs.sl.o at first.

-- 
Aleksey