[cle-release-team] [sakai2-tcc] 2.9.0 key issues [short] list

Wed Oct 31 09:54:07 PDT 2012

Beth, just as a summary.

This entire issue came up because both Omer (at rice)
http://collab.sakaiproject.org/pipermail/sakai-dev/2012-September/018931.html
And Jaco (At opencollab)
http://collab.sakaiproject.org/pipermail/sakai-dev/2012-September/019064.html

Said that there were warnings about sessions getting closed and clusters
leaving when the field on SAKAI_CLUSTER was converted by the 2.9.x script
to "TIMESTAMP WITH TIME ZONE". It should fix the DST problem but caused
this other problem.

Leaving it as DATETIME (the existing field type) would still leave the DST
problem, converting to TIMESTAMP would give you increased precision but
still leave the DST problem.

Converting to TIMESTAMP WITH LOCAL TIME ZONE could potentially resolve both
clustering and DST, or it might break still break the clustering.

So you need both a cluster and daylight savings to test both issues. ;)
Though it sounds like Michigan has that, check your logs for those cluster
INFO messages.

On Wed, Oct 31, 2012 at 12:43 PM, Beth Kirschner <bkirschn at umich.edu> wrote:

> On Oct 31, 2012, at 8:16 AM, David Haines wrote:
>
> > At the moment, given the difficulty of testing the changes, we're
> leaning towards not using KNL-725 and KNL-734 at Michigan.
> >
> While that's true, we're also taking advantage of this weekend's daylight
> savings change, and will be converting our ctools-dev database to
> "TIMESTAMP WITH TIMEZONE" prior to the weekend. In parallel we're reviewing
> the impact of this change.
>
>
> > - Dave
> >
> >
> > On Tue, Oct 30, 2012 at 1:56 PM, Matthew Jones <matthew at longsight.com>
> wrote:
> > Well Seth is on record in the "Sakai Book" with this quote:
> >
> > "Have you any bad practices for a system admin that you would like to
> share? Running a .0 release. In general, this is a bad idea, but Sakai has
> taken this to a new level. I recommend following the maintenance branch
> (.x) instead."
> >
> > Right now though it feels like the biggest problem(s) with the .0
> release are a bunch of things that could really be put into the
> documentation. I feel that whether we release 2.9.0 this week, or wait a
> month this release is a solid release for the people who are either well
> connected to the community, hosted by a commercial affiliate (Longsight has
> a few clients already on 2.9) or involved with the weekly release
> management process to use.
> >
> > There are a ton of lurkers on sakai-dev out there, many on 2.6,2.7 and
> 2.8 who only tune in years after problems are surfaced who will likely
> still run into issues if they don't pay attention to the obvious gotchas
> that everyone on this list knows about.
> >
> > At the moment we've got-
> >
> > - KNL-725 - Probably won't want to convert this column for Oracle, I'd
> just change the timestamp in the conversion script and advise Oracle users
> to either restart after every daylight time switch or set the property
> > expired at org.sakaiproject.cluster.api.ClusterService=4200
> > So that clusters won't expire for 1 hour 10 minutes (default 10
> minutes). This will catch the daylight expiration in either case.  I don't
> currently have Oracle so can't test this out, and was hoping IU or Michigan
> would commit this change or advise further.
> >
> > - SAK-22801 - Normally wouldn't be a problem as the node has to crash
> while triggers are being fired. There is a database cleanup workaround, and
> it might not even affect Oracle or all versions of Mysql. There might be a
> property fix that can be added to a 2.9.x release as well, but just useful
> to know about if your system isn't starting up. (Though I've not seen this
> one yet, so seems unlikely)
> >
> > I'm sure there's other stuff that needs to be better documented like
> optimized cache properties, not to mention all of the other 2.9 properties.
> But nothing that's super serious.
> >
> > In either case, I'll still go through with releasing rc03 (hopefully
> today). Should the tcc have a vote this week on a "go-no-go" on 2.9.0 and
> waiting until all documentation is done? Or just putting the "Seth
> disclaimer" 2.9.0 release. :)
> >
> > On Tue, Oct 30, 2012 at 1:15 PM, Neal Caidin <
> nealcaidin at sakaifoundation.org> wrote:
> > The Oracle scripts do sound like a potential blocker as well, or if we
> go forward with the release this week ,  clear release notes.
> >
> > I am starting to feel torn about the 2.9.0 release.  On the one hand, if
> we can get 2.9.0 released this week (or early next) , then we can make that
> announcement at Educause, but perhaps more importantly it will enable us to
> start thinking about what comes next, for 2.9.1 , which will be essential,
> and then for 2.10. To me, freeing up that energy to focus on the future is
> one of the main drivers for getting 2.9.0 released.
> >
> > On the other hand, maybe it is worth cleaning these things up before the
> release, which would mean a delay in schedule. If we cannot announce at
> Educause, that is a loss, but not the end of the world. I'm more concerned
> about keeping things moving forward with CLE. Which will keep things moving
> forward with the CLE more effectively:  moving forward with the release and
> immediately planning a 2.9.1 with all these things fixed, plus more? or
> delaying the release, and having a cleaner 2.9.0 but pushing out the work
> to have a 2.9.1 ?  If we go for an RC04 (which will be necessary because
> there is no way to get this all in RC03 at this point), we will likely be
> delayed till December.
> >
> > My gut feeling is that we should push on for 2.9.0, get it out the door
> and start planning 2.9.1, but I'm open to the alternative.
> >
> >
> > -- Neal
> >
> >
> >
> > On Oct 30, 2012, at 9:55 AM, Seth Theriault <slt at columbia.edu> wrote:
> >
> > > On Tue, Oct 30, 2012 at 8:53 AM, Neal Caidin
> > > <nealcaidin at sakaifoundation.org> wrote:
> > >
> > >> Does anybody disagree with the proposal to move forward with the
> 2.9.0 release?  I would like to hear
> > >> concerns in advance of Thursday's call, if at all possible,
> especially given our tight timeline.
> > >>
> > >> FYI, I'll highlight these as the top 3 known issues in the release
> documentation.
> > >
> > > Another very large problem are the Oracle timezone-related changes in
> > > KNL-725, KNL-734, and KNL-735; see a previous sakai-dev discussion.
> > > Now, these are in 2.8 and later 2.7s --so they are not new and not a
> > > blocker -- but we need to do something about them. Matt Jones and I
> > > have been discussing them, but we are not sure how to proceed other
> > > than some possible documentation.
> > >
> > > If you haven't made the Oracle SQL changes, you should probably NOT
> > > make them to maintain current behavior.
> > >
> > > Seth
> >
> > _______________________________________________
> > cle-release-team mailing list
> > cle-release-team at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >
> >
> > _______________________________________________
> > sakai2-tcc mailing list
> > sakai2-tcc at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> >
> >
> > _______________________________________________
> > sakai2-tcc mailing list
> > sakai2-tcc at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20121031/1385658a/attachment-0006.html 