Time/Place

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

Attendees 

Agenda

  1. Fedora 4.7.1 release status
  2. Maven GroupId for API-related code
  3. Spec effort: how to trigger fixity checks
    1. Esmé Cowles : via Want-Digest
    2. empty-body POST to a fixity container
    3. just screaming "FIXITY" at your repo
  4. Import/Export sprint update
  5. New public Fedora calendar (iCal)
  6. Defining/Documenting the Fedora API with http://swagger.io/
  7. Comments for participant in last week's Fedora Camp?
  8. ...

  9. Status of "in-flight" tickets

    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.

Ticket Summaries

  1. Please squash a bug!

    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.

  2. Tickets resolved this week:

    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:

    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.   Feodra 4.7.1 release
    • Bethany Seeger kindly volunteered to do the release, and will have a RC later today
  2. Unknown User (acoburn) pointed out fcrepo-vocabulary that represents various RDF vocabularies in Java.  It will be an alternative to our current flawed string-concatenation method.
    • Unknown User (acoburn) wishes to use it soon, but it will have to have a maven release, and to do so, he's suggesting we change the group name from org.fcrepo to org.fcrepo.api (and has issued a PR)
    • A. Soroka has a mild preference for "org.fcrepo" because people more commonly put API stuff there.
    • Unknown User (acoburn) agrees, but would like to avoid reusing/re-purposing existing artifact names and allow for separate version numbers for API stuff
    • Andrew Woods suggested an alternative of instead of changing group names now, just find new artifact names for other stuff later.
      • The approach going forward will be to change implementation-specific group ids.
      • The PR will be closed (not merged) and a release will be made
  3. As A. Soroka moved the spec forward, some questions have come up...
    • How to trigger running fixity checks?
      • Not related to "transmission fixity checks", but instead the "on-demand" fixity checks.
      • Nick Ruest and Benjamin Armintor developed a lovely model, but the question of the exact request is unclear.
        • The model involves creating a new resource (not just a transient part of the response) as the result of the fixity request that contains the current fixity evaluation.
      • The pros and cons of the two proposed methods hinged on whether typically non-mutating HTTP requests resulted in repository mutations and the confusing nature of the meaning and result of empty-body POSTs.
      • Esmé Cowles indicated that choices a and b are not mutually exclusive and we could do an empty-body POST with a want-digest header that specified the algorithm.
      • For clarification...
        • Every binary gets a versioned fixity resource automatically (against which the on-demand fixities can be triggered)
      • There were no objections or suggestions, and a general consensus that either approach was imperfect but acceptable.
      • ...until... Aaron Birkland questioned the need for fixity results to be persisted and wondered if it could be made optional somewhat like the audit pattern
        • Andrew Woods brought up that an advantage to persisting fixity results is that a message gets emitted and that some people have consistently wanted to get notifications (JMS) of those checks.
        • A. Soroka reminded us that we have a principle that we only emit messages when the repository changes, and that if we don't create resources, periodic (scheduled fixity checks) won't make it out of the repository
        • Aaron Birkland played the devil's advocate and walked us through a way one could achieve the expected results without adding this stuff to the spec.  (there was technical difficulties that diminished the ability to hear his arguments)  ... he later continued and asked what is the downside on placing the burden on the user to create a resource to log the fixity and build message receivers to respond to those messages.
          • A. Soroka indicated that some repository implementations may have periodic (repository instigated) fixity checks.
          • A. Soroka also conceded that one clearly could put this outside of the repository and punted to Nick Ruest who deferred to Benjamin Armintor's (absent from call) judgment
          • Andrew Woods asked interested users on the line how they might envision it
            • Jim Coble described their current approach in which the hydra application layer does all the fixity check work and records it outside of the repository (in the Rails active-record database).
            • Doron Shalvi has a use for synchronous request to get a fixity result and has the goal of having routine automated fixity checks and have those values stored somewhere.  The stuff has to be stored somewhere, and it would be convenient to store it in the repository.
        • Danny Bernstein pointed out that the point of fixity was to discover when something was corrupted and asked if messages were emitted when a failure was detected.
          • A. Soroka replied that intentionally there's just an event that indicates the new fixity result and that external tooling would be responsible for determining whether that event identifies a corruption.  He pointed out that in some case (like large videos) an intraframe fixity failure might require a more nuanced response than a simple "FAILED" "SUCCEEDED" binary.
  4. Nick Ruest thinks things are going "Very great"
    1. Summarized here... 2016-12 Import - Export Sprint 03 Meetings
    2. Is working with tool that validates exports as being identical to the repository content (Bethany Seeger's work)
    3. hopes to have real good progress on bag-it work by the end of next week.
  5. Andrew Woods glossed over this due to time, saying that "there is a calendar, it will be updated"
  6. Andrew Woods said this is interesting, we'll give it a look.
  7. Andrew Woods reported that there was a camp and would have encouraged folks int he meeting
    1. Kate reported on the meeting and her interest in a dev-ops interest group


      Andrew Woods will be offline until January

 

 

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.