[Deploying Sakai] Call for feedback on Upgrade Bundle technical requirements/design

Ray Davis ray at media.berkeley.edu
Sat Sep 10 08:25:04 PDT 2011


In this context, I'm not sure what's meant by "manual upgrades." What I 
would mean by "manual upgrade" is something like the SQL scripts we've 
relied on in the Sakai CLE. That sort of manual upgrade is "a pain," 
true. But in a NoSQL data store like the OAE's, such upgrades are 
impossible. Straightforward non-programmed data upgrades are one of the 
things the project lost when it decided to store everything in 
Jackrabbit (and then in SpaseMapContent).

In a schema-less database which doesn't fully support queries on any 
property across the data store, even fairly minor changes to data 
schemas require programmer work.

Also, upgrades currently can only be easily managed on a running OAE 
server, which increases noise and the danger of conflicts. On the CLE, 
we can use a standard SQL client to work on the database while the 
server remains offline. On the OAE, the full OAE is all we currently have.

Given those constraints, and having now gone through a couple of "manual 
upgrades," I don't see much flab in the KERN-2147 proposal.

Best,
Ray

On 9/10/11 7:54 AM, Eli Cochran wrote:
> John,
> I agree that we should do this in stages. Could you elaborate a bit on
> which use cases you feel are "basic" and which you think are "nice to
> haves". I'm sure that would help Chris some up with a plan that properly
> scopes the project.
>
> I know that upgrading is very critical to the pilot institutions. The
> way that OAE stores data makes it very easy to introduce seemingly minor
> changes to the data that result in user facing errors and problems. For
> example, a very small change to the UI to turn-off permissions on
> categories in personal profiles never surfaced for our users because it
> required a tiny data migration. Luckily we caught it in QA. (I'm not
> grumbling, we went to production before 1.0 so that's life.) Now that we
> are at 1.0 and a number of institutions are in production, we need a
> process where all changes like this and more serious ones can be
> captured, documented and migration code written.
>
> Thanks,
> Eli
>
> On Sep 10, 2011, at 1:26 AM, John Norman wrote:
>
>> I'd like to see the problem structured a bit more into stages. It
>> seems to me that there are some basic things that are needed
>> immediately, but others that are potentially nice to have and apply to
>> scenarios that we don't yet experience. Manual upgrades are a pain,
>> but I am not sure how much return on investment this work would
>> produce compared to other priorities.
>>
>> J
>>
>> On 6 Sep 2011, at 19:01, Eli Cochran wrote:
>>
>>> Adding the OAE Pilot Support Group and the front-end devs to this
>>> thread.
>>>
>>> This was one of the high priorities for the pilot support group.
>>>
>>> - Eli
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> *From: *Chris Tweney <chris at media.berkeley.edu
>>>> <mailto:chris at media.berkeley.edu>>
>>>> *Date: *September 2, 2011 2:52:11 PM PDT
>>>> *To: *Nakamura List <sakai-kernel at googlegroups.com
>>>> <mailto:sakai-kernel at googlegroups.com>>
>>>> *Subject: **[sakai-nakamura] Call for feedback on Upgrade Bundle
>>>> technical requirements/design*
>>>> *Reply-To: *sakai-kernel at googlegroups.com
>>>> <mailto:sakai-kernel at googlegroups.com>
>>>>
>>>> Nakamurians,
>>>>
>>>> In the spirit of open community and participation and all those good
>>>> things, I want to solicit input on requirements for an Upgrade
>>>> Bundle. This is the long-awaited tool that will provide a uniform,
>>>> reliable, decoupled framework for tweaking data structures from one
>>>> release to the next.
>>>>
>>>> I've put down a sketchy technical requirements/design at [1].
>>>>
>>>> Please have a look and offer your feedback on list!
>>>>
>>>> Thanks,
>>>>
>>>> -chris
>>>>
>>>> [1]
>>>> https://confluence.sakaiproject.org/display/KERNDOC/KERN-2147+Upgrade+bundle
>>>>
>>>> --
>>>> Chris Tweney, Senior Software Developer
>>>> Educational Technology Services
>>>> University of California, Berkeley
>>>> chris at media.berkeley.edu <mailto:chris at media.berkeley.edu>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Sakai Nakamura" group.
>>>> To post to this group, send email to sakai-kernel at googlegroups.com
>>>> <mailto:sakai-kernel at googlegroups.com>.
>>>> To unsubscribe from this group, send email to
>>>> sakai-kernel+unsubscribe at googlegroups.com
>>>> <mailto:sakai-kernel+unsubscribe at googlegroups.com>.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/sakai-kernel?hl=en.
>>>>
>>>
>>> . . . . . . . . . . . . . . . . . . .
>>>
>>> Eli Cochran
>>> project manager, Cal*Central* project
>>> Educational Technology Services, U.C. Berkeley
>>>
>>> "Software is hard" - Donald Knuth
>>>
>>> _______________________________________________
>>> production mailing list
>>> production at collab.sakaiproject.org
>>> <mailto:production at collab.sakaiproject.org>
>>> http://collab.sakaiproject.org/mailman/listinfo/production
>>>
>>> TO UNSUBSCRIBE: send email to
>>> production-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>>
>> John Norman
>> Director - CARET
>> University of Cambridge
>> john at caret.cam.ac.uk <mailto:john at caret.cam.ac.uk>
>> +44-1223-765367
>>
>
> . . . . . . . . . . . . . . . . . . .
>
> Eli Cochran
> User Interaction Developer &
> Manager of User Experience Design
> Educational Technology Services, UC Berkeley
>
> "The opportunity lost by increasing the amount of blank space is gained
> back with enhanced attention to what remains."
> - John Maeda
>
>
>
>
>
> _______________________________________________
> oae-production mailing list
> oae-production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/oae-production



More information about the production mailing list