Action Decide on Fedora Modules

Assigned

ABR: 2 JRG: 2

Prev assigned

Tasks adressed

["Tasks/3/3"]

Time estimated

4md

Time used

Priority

?

Status

In progress

Iteration

22

Notes

Problem

Decide on the layout of the final production system. Decide which supporting fedora modules should be used, and in what way.

Progress

Identified external modules

• Journaling
• Akubra
• OAI-Provider
• GSearch
• Tripple store
• REST API
• Database

Identified internal modules

• Domsclient
• Bitstorage
• ECM
• GUI
• Summa

Journaling

Journaling provides us with the option to always have a up2date mirror of the running repository. We cannot use this mirror for load balancing, while mirroring Possible scenarios

1. Primary server fails, we switch server and is up and running in no time
2. Primary server is momentarily overloaded. We turn off update requests (ie. the GUI) and let both servers handle the load.

This use of this functionality is heavily dependent on the uptime requirements to the final system. Inquiries in this direction have begun

Akubra

Akubra blob storage lives on http://www.fedora-commons.org/confluence/display/AKUBRA/Akubra+Project It is a storage layer abstraction. At the moment it is in version 0.1, but in time it will grow to become the storage layer of Fedora.

The basic idea is a BlobStore, storing Blobs. These can be gotten back, and new ones can be made. At the moment, the DOMS system have to very different storage mechanisms, the one in Bitstorage, and the foxml storage. The akubra project would naturally integrate on top of the foxml storage. The specific system in Bitstorage is more of a problem, through. To use Akubra on the Bitstorage would require a fundamental redesign of how files are handled in DOMS.

It is the recommendation of this group that Akubra not be used in DOMS. Further investigations into managed datastreams in Fedora would be worthwhile and might change the decision.

OAI-Provider

http://fedora-commons.org/confluence/display/FCSVCS/OAI+Provider+Service+1.2

The OAI-Provider service

Conclusion

Checklist For Working On An Action

The Life Cycle of an Action:

• Assign people for action definition: Done at start of iteration status meeting. Fill out Assigned

• Define the action: Describe information about what is to be done and how. Fill out Tasks Addressed and Time Estimated.

• Review the definition: Get another project group member to review the action definition, and update it.

• Assign people for action implementation: Done by project manager, usually the same persons who wrote the definition. Fill out Assigned and Prev assigned if new persons are assigned.

• Implement the action: See details below

• Review the action: Get another project group member to review what is implemented (code and documentation), and update it.

• Finish the action: Change the status to "Finished" and update the "time used" field on the action page.

Please make sure that you address the below issues, when working on an action:

• Update the state of the action to "In Progress" when you start working on it.
• Check if the tasks addressed by this action have their status set to "In Progress". If that is not the case, then change the state of them.

• Keep track of how much time that has been spent working on the action. If it addresses more than one task, then make a note on the action page about how much of the elapsed time that has been spent on the individual tasks. Hint: Continually updating the "Time used" field will make it easier for you.

• Update the "Progress History" and documentation pages of each task addressed by this action when appropriate. This depends on the situation, but in general, the task pages should hold all important related information about the work done, experiences gathered, identified requirements and so on.