Regular Attendees

  • Andrew
  • Bill
  • Brad (star) but we will switch off so no one has to do too much.
  • Chris
  • Dan
  • Jonathan (Presumed at CNI)
  • Danny

General

  • Call In To: Free Conference Call HD - DuraCloud Line

    Please note that we will be using the Free Conference Call HD line for this call. Information about calling into this line is available from the link above.

  • (star) - Indicates who will be taking minutes

The meeting will be in two parts:

First Part 11-1
Break
Second Part 3-5

Discussion Topics

Useful Definitions

CSF = Critcal Success Factor
Risk = Not a negative but just a potential barrier to progress which needs to be identified and mitigated

What forms a critical code mass?

CSF - We should have an integrated product by the end of 0.2 upon which we can add features incrementally.

Question: What components/services are in this mix?

  • one or more client sources
  • full hook shot through DuraCloud, Fedora, and back into DuraCloud
  • SI frontend
  • security throughout
    Question: What are the set of features per component we can do in 0.2?

Synchronization Service Watcher

  • Additions to existing code?

Object Creation Service

  • Convert to Apache Camel
  • Deploy in Spring
  • Add Droid (without OSGI this time?)

Question: What is the development/demonstration environment?

CSF - Demonstration Stories

Question: How do we explain what is working and what is to be developed?

CSF - Partners

CSF - UI Work

  • Both for support base functionality?
  • As a way to provide requirements and human factors information?
  • Is the concentration mostly on the Synchronization Setup functionality?

Question: How do we want to engage researchers in 0.2?
Question: How do we want to work with SI in 0.2?

Risks (and how to mitigate them)

SI - What is there are problems integrating with SI from an information perspective?
SI - What if there are problems integration with SI from an security perspective?
SI - What do we do if we need to alter SI code?
SI - Can we demonstrate SI in an integrated fashion in 0.2?
SI - Is base Islandora a fallback?

Minutes

  • Dan intros:  Meeting in two parts; notetaking to switch off.  Plan to cover the four existing cards, then move to new planning.
  • Review of open existing cards for DfR 0.1:
    • DFR-78 will be completed this week.
    • DFR-23 moves to DfR 0.2, and will be factored into smaller tasks.
    • DFR-74 DURACLOUD-575 closed today; waiting on DFR-76 (which went to DfR-0.2, and may move under epic).  Closing DFR-74.
    • Need to write up release notes.
  • Goals for this meeting, and for DfR 0.2:
    • Complete end to end system that we can then add features to.
    • Need to clearly establish what can be built in the two month iteration.
      • Expect design, storyboards, tech selection, wireframes; get validated by researchers in the project.
      • Do DuraCloud deliverables represent a challenge for scheduling of DfR deliverables?
      • (Discussion; will most deliverables be from Peter; can we get the planning done for Peter while the DuraCloud release is pending?)
    • For 0.2 goal is to get a basis; get all major components of the path in place, expose any risks, and be prepared to add features.
    • Do we want to cover the administrator or curator views in 0.2?
      • Implied as part of basic account structure and identity and group management
      • Rough out reporting and notification (are these the same technology base)
    • Security for 0.2:
      • All components with UIs will support Shib (entering user/pw flows throw shib provider).
      • All service to service / non-browser interactions continue to flow via basic auth - with an access key associated with user account, not user/pw.
      • Incorporate same into DuraCloud and DuraCloud management console and Fedora interaction and the SI UI.
      • (DuraCloud was moving in this direction anyway for InCommon).
      • Note that fine grained modeling of auth and associated UIs is expected to occur in a later iteration; determined by when user designs available.
      • Not dealing with Fedora level fine grained access until later (but mechanism to be tested)
    • SI Islandora for 0.2:
      • Show basic tree of content.
      • Not all SI content models supported.  Possible stretch goal to have one data set that goes to SI content models and shows visualization.
      • Can we show an exhibit display (Hydra/blacklight based) as a strong demo.  (Can we get someone from Hydra to build this)
      • We will need to choose the example data set and work towards the Fedora model to make that work.
    • Search capability for a future version?
      • Is this by 0.4, or 0.5 and beyond.
    • Two-way or multiway sync by 0.4?
      • NB difference between multiway sync and restore.
      • (Discussion)
      • Three Q's:
        • Will we do multiway ever?
        • How would we push augmented metadata back upstream (if we do)?
        • What do we guarantee / not guarantee if the user aggressively creates an unsupported multiway environment?
      • Decision:  Place these into a phase two (not in DfR 0.1 through 0.4).
    • Object characterization (e.g. format) in 0.2.
    • Expect to add content models incrementally.
      • 0.2:  something; (one content model and examine Islandora to understand the risks).  Also advanced processing in format characterization, ideally from a real data set.
      • 0.3:  add more, ...
    • What do we need to do about async vs sync around the OCS etc for 0.2?
      • Nothing?  Small delays aren't expected to be a problem in the short term.
    • Hookshot for 0.2:
      • Researcher places content on local data system;  watched by sync
      • Sync pushes to duracloud
      • Duracloud tells OCS, OCS pushes into Fedora
      • Fedora sends object back via cloudsync.
      • Can then find the file in Duracloud, see it in Fedora, and discover in SI frontend.

Need to define encryption strategy in 0.2 (strategy, not impl)

    •  OCS / microservices
    •  

Notes for Iteration Planning 2012-04-09

  • DFR-74 - DFR012 - DF02
  • DFR-76 Under Epic?
  • DFR Chat Last Week.
  • Expectations for Peter and Danny. What are needs to get started.
  • Full core code
  • Design, Wireframes, Technology Selection, validation with Researchers. DuraCloud deliverables.
  • What time is available? From Danny, from Everyone Else.
  • Bill Clients - Windows-client, Mac-client, Linux-client. Andrew meant what Bill meant.
  • Brad - Adminstrator not called out. Curator. Accounts, Identity and group managements. Reporting framework and debugging not to become a risk.
  • Notification - TBD
  • 0.2 Diagrams need to be started. -TBD
  • Security - How far in 0.2?
  • All UIs have Shib!
  • Service-to-service interactions have basing authN, authZ.
  • RESTful basic authN.
  • Bill: Follows for inCommon work.
  • Andrew: Basic Admin, AuthZ for course-grained. Later, than for toward post 0.2.
  • Jonathon: Content tree in demo in 0.2
  • Brad: Stretch goal - hook to SI content model
  • Dan: Just not SI.
  • Bill: Other sorts of presentation - Look at Hydra/Blacklight post 0.2, Get help from Hydra
  • Brad: Find a good data set underlying issue, finding might be 0.2 risk mitigation
  • Dan: Private search post 0.2 post 0.3
  • Synch tool: Additional capabilities post 0.4. Two way, Multi-way synch happens in the future.
  • Brad: What if user starts doing multi-way synch outside the environment. What happens.
  • Why would anyone put our synch tool in their environment.
  • Future: Micro-service Execution Environment
  • Bracket: In first forty minutes
  • Format: As an 0.2 format function.
  • Jonathan: More heterogenous demonstration
  • Spell out - Full Hook Shot
    • 0.2 Research puts content on local file system.
    • To OCS.
    • Back to DuraCloud.
  • GUI - Designed - Using primitive UI.
  • Bill: Stategy for Installing Monitor and Synch tooling, technology approach.
  • Encryption: After 0.2. Define what we want to do.
    MEE: OCS is steps within
  • No labels

1 Comment

  1. Notes for 3rd Hour

    Metadata Collected at Ingest

    • 3 Sources:
      1. File based metadata
      2. Metadata defined by the importer
      3. Stuff that can be entered from SI
    1. Add rules to directories?
    2. Autogenerated controlled vocabulary from SI or Fedora or potentially public sources such as Wikipedia to present a set of tag, metadata options.
    3. What is the absolute minimum to make things work at all?
    4. Ideally point and click interface with more customized entry available as well.

    Configurable Service Infrastructure

    1. could be a high value proposition
    2. lots of tools available
      1. Adam Soroka has a lot of experience with workflow framework technologies
      2. Mule is a good example, Apache Camel
      3. What capabilities are we actually looking to deliver? Focus on the capabilities and not frameworks.
        1. format characterization
        2. Extracting interesting information from images or video
        3. consistency check between fedora and duracloud
        4. extracting geolocation information
        5. image conversion
        6. thumbnail generation
        7. index building
        8. duracloud service runner
        9. elegant REST-ful services caller
        10. GUI editor for workflows
        11. c,python, ruby wrappers
      4. We need to choose soon, so that we can grow with it:
        1. Action Items for 0.2:
          1. build up criteria
          2. make a choice as a group.
          3. use it to demonstrate format characterization (Droid)
          4. Look into FITS tooling
          5. It would also be nice to demonstrate an interesting data extraction.

    Notification

    • Nothing fancy needed at the moment.
    • JMS initially for internal event-driven activities.
    • Eventually we will need to provide Email notification as well.
    • JMS will come in handy for reporting
    • Might be useful to reflect on our user stories.
    • Action Items:
      1. Define the use cases where messaging is going to be useful.
      2. At minimum, set up message broker to build on communication between DuraCloud and Fedora
      3. failures: failure to create objects
    1. User story: demonstrate making content extraction searchable via front-end.
    2. Full text search by 0.3 or 0.4