Sprinting to Fedora4: More on Clustering, Transactions, Versioning, Pluggable Framework in Sprint B11

Tue, 2014-03-04 14:19 -- carol

Winchester, MA  The Fedora team has concluded the eleventh sprint within the "Beta Phase" of Fedora4 development. The work of this and each sprint is planned and completed thanks to the contributions of Fedora stakeholder institutions which allocate developer time. If you would like to be involved with Fedora4 development, please send an email to Andrew Woods awoods@duraspace.org, or to fedora-community@googlegroups.com. If you have comments on the work from this sprint, please also send an email or comment directly on the wiki.

Read the the Sprint B11 summary:
https://wiki.duraspace.org/display/FF/Sprint+B11+Summary

About Sprint 11, Beta Phase

Development Team

Frank Asseg - FIZ Karlsruhe
Adam Soroka - University of Virginia
Michael Durbin - University of Virginia
Scott Prater - University of Wisconsin
Greg Jansen - University of North Carolina, Chapel Hill
Ben Pennell - University of North Carolina, Chapel Hill
Mike Daines - University of North Carolina, Chapel Hill
Osman Din - Yale University
Eric James - Yale University

Sprint Themes

1) Clustering
The clustering feature of Fedora 4 holds the promise to address a range of use cases from horizontal load-scaling, to high availability, to geographic distribution. The short-term goal is to demonstrate a proportional increase in performance with the addition of cluster nodes for load-intensive operations such as object creation. Previous work has focused on the simple establishment of multi-node clusters along with configuration experiments towards optimizing object creation.

This sprint furthered the effort by establishing Fedora 4 clusters [1] at two additional institutions. While the focus is on determining which underlying ModeShape and Infinispan configurations optimize stakeholder use cases, a parallel effort was put towards developing repeatable, scripted Puppet deployments.

2) Transactions
Transactions [2] are important not only for bounding a set of repository interactions into a single, atomic unit, but also for their performance benefits. Much of the time in a user request goes towards the saving or commit of the action's update(s) to the repository. Transactions offer the potential of grouping a set of interactions, and their associated persistence events, into a single commit.

A bug which prevented transactions across different HTTP sessions was fixed during this sprint through a community contribution (Kai Strnad). Further profiling of the exact performance benefits of transactions on a variety of actions (creation, update, deletion) is outstanding.

3) Versioning
The Alpha-3 implementation of versioning [3] exposed previous versions of a repository resource in the case where no authorization was configured on the repository. This sprint extends the basic functionality by exposing versions to users that have read access to the resource, if authorization is enable.

4) Pluggable Framework
As of the Alpha-3 release, Fedora 4 has been demonstrably "easy" to install/deploy. Work during this sprint was put into the design and prototyping of a wiring and pluggability framework that would additionally make the runtime configuration of Fedora 4 "easy".

5) Test Coverage
Having a comprehensive suite of unit and integration tests affords the Fedora 4 code-base with greater resilience to rippling bugs, demonstrations of expected usage patterns of the APIs and components, as well as enables architectural refactoring to occur with less risk. A focus of this sprint was to increase our test coverage [4].

The sprint started with 64.5% unit and 71.4% integration 83.8% total test coverage. The sprint ended with 71.3% , 71.1%, and 84.4%, respectively.

6) Housekeeping
Several bugs were addressed during this sprint along with the addition of tests that provoke the would-be bug scenarios. Bug fixes and application polishing included:

• Catching errors when submitting an empty admin search query
• Creating an "authorization-enabled" deployable war file on the default build
• Upgrading the underlying ModeShape version to 3.7.1
• Exposing primary types, mixin-types and each of their ancestor hierarchies in responses, which enables indexing to be aware of resource super-types
• Creating resources on a PUT request if it does not exist
• Consolidation of previously dispersed configuration files
• Correcting the syntax of the LDP "Link" header, as surfaced through community input
• Addition of authorization unit tests

7) Developer Capacity
For the short and long-term health of Fedora development, the committer base must continue to expand. This sprint witnessed the addition of two new developers from the University of North Carolina, Chapel Hill.

References

[1] https://wiki.duraspace.org/display/FF/Clustering

[2] https://wiki.duraspace.org/display/FF/Transactions

[3] https://wiki.duraspace.org/display/FF/Versioning

[4] http://sonar.fcrepo.org/dashboard/index/1

RSS Feeds: 
preserve