Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Danny Bernstein
  2. Peter Eichman 
  3. Bethany Seeger (star)
  4. Jared Whiklo
  5. Andrew Woods
  6. Kevin Ford
  7. Michael Durbin
  8. Ben Pennell 
  9. Aaron Birkland  


Agenda

  1. Announcements

  2. Sprint 2 Strategy and Goals
    1. Release candidate
      1. Vagrant
      2. Camel toolbox 
      3. java client
  3. Open questions: 

    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2730
      1. 4 Integration tests in FedoraLdpIT are breaking due to a 500 Error.  
      2. The cause of the 500 is

        Code Block
         javax.jcr.RepositoryException: The session with an ID of '060742fc6' has been closed and can no longer be used.


      3. It appears to be an OSX 10.13.x issue :  Jared WhikloPeter Eichman, and Danny Bernstein have reproduced.
        1. Danny Bernstein confirmed It was not a problem for OSX 10.10.5
        2. Any ideas of how to solve it? 
      4. If we can't resolve it,  what are our options? 
        1. Leave the tests in place - and document the problem in the README.
        2. @Ignore  the tests until we can sort out the issue or it sorts itself out (OS fix)
        3. ?
    2. Data URIs in the constrainedBy link header
      1. https://github.com/fcrepo4/fcrepo4/commit/750426101de9330cafaa88838a3d694d1ef69580#diff-14e2f9192b9abd40557a43f9342f4481R44
    Sprint 2 readiness
      1. Proposal:  Remove and use standard URIs instead like we do with all other constraints.
    1. Prefer headers on Mementos:  https://github.com/fcrepo4/fcrepo4/pull/1420 
      1. Question1:  Should the original resource return  <> a ldp:Container and <> a ldp:RDFSource  when omitting server managed triples (currently these are being omitted in OriginalResource but not the Memento)
      2. Question2: How should fedora respond to requests to Prefer omit
        1. What would a use case for omitting server managed triples in memento?
        2. Proposal 1:  Mementos should behave like the original resource
            1. Rationale?
            2. Action:  based on the answer to Question1 either omit the ldp types from memento or add them to the original resource response
        3. Proposal 2:  Mementos should not respond to Prefer omit
            1. Rationale? 
        4. Proposal 3: ?
    2. All AuthZ tests assume literal agent values
      1. What is the best way to fix this problem?
  4. <your agenda item here>

  5. Please squash a bug!

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13122
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


  6. Tickets resolved this week:

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13111
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


  7. Tickets created this week:

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13029
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


Minutes

  1. Next sprint starts next week!

  2. Lots of work happened during the sprint - many CTS tests filled in.  Nice job!
  3. Sprint 2 Strategy and Goals
    1. Goal: get to the Release Candidate
      1. There are a number of tickets there that we know we want to address.  Priority on those first. 
      2. Setup Release Testing work - pages, testing that the process still works and address any issues seen.  
      3. Documentation
      4. Jared suggests focusing on the maybe 5 tickets that are bugs, leaving new features for later.  
        1. Suggestion of looking at all tickets to prioritize them. 
      5. Someone can look at fcrepo-camel-toolbox and java client to get an idea of what needs to be done there.  
    2. Secondary Goal: tool set.  Priority would be to update camel-toolbox and java client first, vagrant last (as it depends on the other things and may not be much more work to update). 
      1. Ben P. suggests documenting the changes that are needed to the fcrepo tool set: fcrepo-camel-tool box, java client. 
  4. Open questions: 

    1. Jira
      serverDuraSpace JIRA
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
      keyFCREPO-2730
      1. Tests are old tests, but they only break on this branch based on new stuff Jared is doing in his PR. 
      2. Mac 10.10.5 doesn't show this error.   (10.10.3 = Yosemite)
      3. 4 tests failing in FedoraLDPIT tests.  Same 4 tests failing.  Something to do with setting text HTML in header - to return the web page. Maybe something to do with how Grizzy is working; may be a timing issue. 
      4. Peter E. Do we think this is a network/stack/socket communication problem?  Any leads on what's causing it? He's seen some weirdness in their batch loading clients in the network HTTP/TCP stack that weren't working in Mac OS High Sierra, but worked on Sierra. High Sierra may have broken some networking issues.   Danny B. suggests leaving it since it may be a Mac issue - but many of us use Mac OS's to build; we'd have to ignore those tests.  Can we do a conditional ignore on Mac OSX's?
      5. Jared suggests we try to look at this more.  In the test, in Velocity the SessionFactory and http servlet request is injected, using context...?.  Maybe something he's written there is not the best way to do this.  Info he's trying to get is that it needs to know if it is a memento and if it's versionable.   Maybe there's an easier/better way to get that data?
      6. One proposal – have someone look at it now
      7. Or make a ticket, put a conditional ignore on the tests, put some manual tests for this in the release plan, and keep moving forward, addressing this later. 
      8. Ben Pennell may take a short look at it. (He has a High Sierra mac)
    2. Data URIs in the constrainedBy link header
      1. Default response on malformed RDF is a Data URI in the constrained By link. We are not using data uris anywhere else.  You can't just easily read the response and see what's happening there.  
      2. No objection to changing that.  Danny B. will create a PR.
    3. Prefer headers on Mementos:  https://github.com/fcrepo4/fcrepo4/pull/1420
      1. Question1:  Should the original resource return  <> a ldp:Container and <> a ldp:RDFSource  when omitting server managed triples (currently these are being omitted in OriginalResource but not the Memento)
        1. The thought is that this is a new bug - that the original resource should return those two triples.  Danny B will create this ticket. 
        2. Danny B will create a documentation ticket for what the SMT's actually are. 
      2. Question2: How should fedora respond to requests to Prefer omit
        1. In theory they should be the same - that what you see with the original based on the representation request, should look the same in the memento. 
        2. Proposal 1:  Mementos should behave like the original resource
            1. We'd like to go with this. 
    4. All AuthZ tests assume literal agent values
      1. Danny believes we have some way to handle this. You can specify the baseURI for agents?  The actual logic is backwards from expected. It retains the comparison between the username from current user and the agent value - is still a string comparison of just the user name.  The BaseURI user webac uri prefix, its not being added to the principal from the container, but it is being stripped coming from the WebAC. Logically you end up comparing things in the correct sort of way. 
      2. Maybe the fix is to make sure that the values going into the ACL's are URIs.  Any of the agents that are being tested by the CTS should probably be URI's.  Then when running against fedora, we'd have to specify the agent base URI to start up the server with. 
      3. Need to start collecting a recipe of how to configure your fedora to run the CTS on it.   (external content setup, webac agent setup, etc)
      4. CTS is assuming HTTP basic auth; leaving out server certs, OAuth, etc.. What should we support?  What does the Fedora API have to say about how it get a user name from the request? Is anything specified for that?
      5. WebID passed in the header? WebID TLS - auth using WebID – Solid spec mentions this by name. https://github.com/solid/solid-spec#webid-tls
      6. Maybe create an issue for this and address it during the upcoming sprint. 
      7. Solid spec mention WebID and WebID TLS, but don't seem to be musts. 
      8. Question of what are we assuming about WebID based on what Solid requires?
      9. Zimeon raised a point about users and names and we should check in with him
      10. All of CTS assumes basic auth but some systems may not be using basic auth. Would be hard to cover testing all auth systems.  We could work with folks implementing the spec and see what they are using. 
      11. Aaron Birkland mentioned CLAW and JWT's - solution was to have the system hand off a http client off to APIX, which does all the JWT stuff.  We could add an authentication interface for the CTS  in order to delegate authentication to the implementation. The tradeoff – Fedora implementors will  have to implement the interface.   However, this approach might be more practical than trying to support specific systems folks are using. 
  5. Announcements

    1. Danny sang a song about announcements
  6. Sprint progress/checkin
    1. CTS has a few small bugs and feature requests remaining, almost all the tests complete
      1. Jared is going to try 6.1 notification events.

      2. Still need the machinary to listen to the notifications.

      3. Modeshape sends out a lot of notifications that are "not exactly modifications"

      4. Is there an example of what is strictly expected in terms of format? It may be difficult to test

        1. There are a few MUSTs which are testable, such as identifier and activity stream namespace

      5. awoods: There are about 17 issues, do we want to defer them or do they need to be addressed now or can some be closed?

        1. danny will go through the tickets to try to make this determination, awoods will double check
  7. Issues to discuss
    1. Reviewing tickets in the sprint board https://jira.duraspace.org/secure/RapidBoard.jspa?rapidView=40
      1. 2730 - It may be operating system related

      2. 2778 - mostly done, tests mostly passing, but there is one that may or may not be related that is failing

      3. 2848 - the actual ticket is done. But there is an issue with date formatting, something that is formatting the dates is changing the significant digits which is actually changing the timestamp if a timestamp ends with a 0. So 140 milliseconds becomes 14 milliseconds in the memento.

        1. Danny - create another ticket for this second issue

        2. Bethany - sure, but we wouldn't want to merge this issue until the second ticket is addressed. Bethany still interested in keeping her name on the ticket

        3. Danny - maybe a second ticket isn't necessary since the issue is documented in the original ticket

      4. 2854 "Defining acl:accessToClass without an acl:default predicate has no benefit" - has been converted to a documentation ticket. Basically warn people that if they are doing something, it probably doesn't do what they think it does.

      5. cts208 - was merged yesterday

      6. cts206 (Inheritance and Default ACLs)
        1. The issue was that there is no definition for what the backstop ACL should be, and that there is no requirement that the default acl be exposed.
        2. peter: two suggestions:
          1. have a way to retrieve the effective authorization per node regardless of whether something is directly assigned,
          2. or just expose the backstop ACL explicitly off of the root node (this would just solve the initial testability issue)
        3. Peter will begin creating a sidecar modification for spec related to this.
        4. Do a 404 check for the time being.
      7. 2092
        Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyFCREPO-2092
        has existed for a year, may not be essential.
        1. IndirectContainer related. There were triples not being persisted.
        2. Medium gnarl, luke-warm interest, so may not be essential for version 5.0
  8. Newsletter
    1. Should we co-opt the existing newsletter, or send a separate tech update message?
    2. Updates on sprint progress, effort to remove modeshape dependencies, state of the 5.0 effort.
    3. Have a link from the newsletter to the tech update
    4. Danny will compile first edition of the tech update letter. "The road to no Modeshape"

Future Agenda Topics: