The student parking effort is progressing nicely with almost 3000 students signing up for the parking spot draw process.
Registration is closing early next week. A new bunch of code is going up onto JUMP to help with the next phases. This code should be in place in production on Friday morning.
Last week found out we were facing a new defect with the migration. In this case admin permissions for manipulating channels were missing after the migration. With suggestions from Sungard over the weekend I installed LP IV on romulus and performed another migration.
This time post migration we have access to these admin level functions. So prior to this post things were in good shape for Debbie and Brian to test, not so for Dave, Naramada, and Bill. But now everyone can take part on vulcan (lumnext.cc.umanitoba.ca) to fix up the custom channels. Perhaps on the weekend I will try and put in some of my new custom channels.
Alright no real dancing but still some excellent news. Sungard reviewed the log files from Friday and Saturday and they all look good. Today I transferred over all the group/course tools files from June of last year (when we did the snapshot) to vulcan.
I am currently working with Sungard to resolve the odd issue with decreased admin access once logged into the portal. I still need to bring over the mb_topics table but once that is done I think we can open it up for testing.
Keep in mind the testing to be done is to confirm that the data present in the groups and courses is accurate. The testing is not for commenting on broken channels as we know that all custom channels we have developed will most likely be broken. There is one exception in that if a channel is not a custom channel (i.e. targetted content, or old school RSS) and it does not appear to have been migrated properly we need to know about it.
All feed back needs to be done via bugzilla, there is a new component called migration to track these issues in.
About bloody time! I have been able to migrate the Luminis III data to Luminis IV. There are some fine touches that need to yet be done. Specifically:
- migrate mb_topics by hand
- migrate calendar data
- migrate the group and course files and photos
- put back the custom CAR files
Those were given issues from the outset of this process, which I will work on, on Monday. Now the data present in this system goes back to June of last year.
Perhaps I should not shout from the rooftops just yet, but I was actually able to log in and see a fairly functional portal unlike previous attempts where the bulk of the channels were broken.
The url for those that monitor this blog is http://lumnext.cc.umanitoba.ca
The main issue affecting us currently is the small change to the baseDN suffix in Luminis IV. We have been told that if we make it the same the migration script should work. However the migration script is also meant to handle such a change.
Well today it looks like I may have tracked down the reason for the issue. In all the translations that the mgiration script does, it does not translate the property values from the old system before loading them into the new system. As such the old system does contain various properties that contain an LDAP baseDN. These are used by the system when it is running, but also later parts of the migration for fixing the data. I have adjusted their code that does perform some modifications to the source system property file to correct the values and in tests this afternoon it produces the correct file.
In a few moments I will start up the job that will perform the full migration tonight to see if this resolves things. Of course we will not know anything until tomorrow, I also hope the oracle team gets my e-mail in time to disable the lp4prod recycle.
Well look at that they did get it and it has been disabled. Yeah!
We met with the Parking office yesterday and are now finalizing the Draw-hold, Draw and Notify phases. In each phase, a user may either:
- see their draw process registration
- see their status, if they are on the waitlist
- be offered a chance to go on the waitlist
Some tweaking of the display is in process, and screen shots are going out to Parking once the changes are in place in development.
In regards to the migration it would appear that the belief Sungard had in regards to changing LDAP suffix causing the problem was incorrect. The problem was directly tied to attempting to move over a layout owner that did not exist in the list of users being loaded into Luminis IV. Once I removed this layout section from the dlm.xml file we were able to get farther. However we then stumbled on an issue with updating the LDAP with the layout owner information in the dlm.xml file.
This was due to there already existing layout information in the LDAP. The suggestion from Sungard for this was to reset the Luminis IV data and manually delete the layout information present so that the migration tool could insert the data from Luminis III.
This was done on Friday last week and we postponed the Luminis IV database recycle so that it could run through Saturday. We have now got even further then before. There is still an error in the output that I am having Sungard evaluate to determine if it is of a critical nature.
So in short the things that we have done to make the migration work:
1. Increase the error threshold to 2 as there is a known problem with the migration of the mb_topic table and UTF8
2. Migrate the mb_topic table manually as there is no translation being done on this table other then the dropping of one column
3. Ensure that there are no fragment entries in ou=site,o=Luminis Configuration, the cn pattern will look like org.jasig.portal.layout.dlm.fragments.data.?? where ?? is a number