Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

• Time: 11:00am Eastern Daylight Time US (UTC-4)
• Dial-in Number: (712) 775-7035
  • Participant Code: 479307#
  • International numbers: Conference Call Information
  • Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
• IRC:
  
  • Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #fcrepo on irc.freenode.net

Attendees 

• Jared Whiklo 
• Andrew Woods
• Unknown User (acoburn)
• Bethany Seeger 
• David Wilcox
• Andy Wagner

Agenda

1. Vulnerability: Java object serialization

   1. http://fishbowl.pastiche.org/2015/11/09/java_serialization_bug/ 
   2. http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

2. Modeshape5: https://developer.jboss.org/message/945504

   1. Plan
      • standard API
      • multiple impls
        • f4 over mode w/level-db
        • f4 over mode w/jdbc
        • f4 over casandra
   2. Considerations
      • minimize migrations
      • simplify migrations
3. IDCC F4 workshop in Amsterdam – Fedora committer volunteers?
4. Nov/Dec/Jan plans
   1. consider upcoming travel

5. ...

Ticket Summaries

1. Please squash a bug!

   Click here to expand...

   type	key	summary	assignee	reporter	priority	status	resolution	created	updated	due
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

2. Tickets resolved this week:

   Click here to expand...

   key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

3. Tickets created this week:

   Click here to expand...

   key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution
   Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Minutes

1. Java Serialization Vulnerability - (see email thread) Andrew Woods, Benjamin Armintor, Unknown User (acoburn) have all looked into this and concluded that this does not affect fedora4.

2. Modeshape5 - modeshape community is moving away from infinispan because in cluster configuration they are unable to maintain consistency. modeshape is now focused on "scaling up" rather than "scaling out". Perhaps infinispan will return later.
   1. Fedora currently relies on infinispan and has been advertising the clustering capabilities of modeshape/infinispan.
   2. Standard API - "retrenching on fedora API"  
      1. fcrepo-kernel-api.  There's not much code there, but a set of interface used to define how the implementation looks and interacts with world.  That API no longer depends on modeshape.  It does still depend on JCR.  Aaron Coburn and, most likely, Adam Soroka would like to see that removed from API.  
      2. There's a bit of modeshape bleed into the other project's outside of fcrepo-kernel-modeshape. Ie. file connector module and authorization module.  The other modules need to be clear of modeshape (jms module is, but the http ones aren't, yet).
      3. We want this to be a fedora API based on community needs, and not have it linked to one product. 
      4. Standard API really needs to be worked on more before implementing an alternate fedora that doesn't use JCR or modeshape.  Aaron has been pulling modeshape and JCR out where possible.  Need to clean up (or make sure) the RESTful interface doesn't reference JCR/modeshape.  The sooner we do this, the better it will be so that fedora users don't assume that these JCR/modeshape things will be there. 
      5. Tickets related to this: 
         1. Ticket:   Unable to locate Jira server for this macro. It may be due to Application Link configuration.
         2. Ticket:  Unable to locate Jira server for this macro. It may be due to Application Link configuration.
         3. Are there clearly defined pieces that people can work on?  Create sub-tasks for these tickets? 
      6. What is the most efficient way to have a conversation that includes everyone regarding this issue? Wiki page with epic in Jira?  Break this down to where the remaining work is.   And ensure that the community is aware of some of these efforts and knows what direction fedora is going in.
         1. Communicate to the community about why fedora is making these decisions.  And how these are motivated by real events (modeshape), versus strictly theoretical.
   3. implementations
      1. The way information is persisted right now in infinispan => leveldb (default case).   Even if modeshape supports leveldb under the cover it may land differently in level db then how it is now, after the modeshape 5 migration.
      2. Completely different implementation – Cassandra db, tripplestore implementation of fedora.  
      3. We need to put energy into the transistion for modeshape4 -> modeshape5 implmentation.  Fedora3 -> Fedora4 is a bit of work, so we want to try to make this as simple as possible for the community.
         1. key thing - keeping the REST API the same to the greatest extent possible. The application interaction (REST) we don't want to change (or minimally change), and the data aspect underneath - data migration involved as well. 
         2. Backup restore for modeshape may have limits.  That might be helpful for migrating modeshape 4 to 5.  What will they be putting in place for migration? 
   4. Consideration on when folks who are thinking about migrating to fedora 4 now need to be aware of this modeshape 5 change as well.  
      1. It may give folks a moment of pause in thinking about migrating and when they should migrate. 
      2. Folks could migrate to fedora 4 and then it's incumbent on fedora team to make subsequent migrations as seamless as possible. 
   5. Test compatibility kit (TCK) - for having some kind of TCK that verifies that the resulting fedora is still what it promised to be. 
   6. Put a message out to fedora tech to get some momentum in moving towards API changes that we've been talking about for a while as well as to spread the word about the long term (1-2 year) changes that are being discussed. Fedora Tech only at this point?  The changes discussed here shouldn't impact the client API so the user interaction shouldn't change.   Maybe a heads-up to the broader community (that they might bring up ideas that they have had regarding things they want to try)?  How do we frame this in a way that it's positive and that this doesn't precipitate moving away from modeshape, but it does mean we may need to move quicker to meet our goals.   
      1. Who is interested in this information?  tech folks, managers? 
      2. idea of clustering - maybe recommend people don't do that for a while 
         1. if folks are working with a standard, better fedora API, then going back to clustering should be easier.  ??
         2. Explore this a bit more before presenting it to a larger community?   Many projects are changing right now (hydra, islandora) and we don't want to scare folks that fedora is changing a lot as well. 
         3. Unknown User (acoburn) is interested in horizontal scaling.  Essentially there's a large community with the same goal in mind and clustering is important. 
3. Contact Andrew Woods or David Wilcox if you're interested in presenting about fedora at a conference in Amsterdam in February (http://www.dcc.ac.uk/events/international-digital-curation-conference-idcc).