20180815 - Aug 15, 2018 - Technical Council Meeting Notes

Owned by Tod Olson
Last updated: May 07, 2019 by Mike Gorrell
2 min read

Date

Attendees

Guests

Goals

  • Wrap up hard-coded lists quickly
    • what kind of tools are available to help module builders make controlled vocabularies?
    • do module builders know about these these tools, do they need encouragement?
  • Expand AES discussion and resolve questions on draft AES document
    • Try to make as much progress out of band before meeting
  • Main event: Workflow discussion. Consider this presentation
    • Come to agreement on resources on scoping Camunda implementation (slide 11)

    • Discuss steps and timeframes for teams integrating with Camunda and then coming up to speed (slide 12)

  • Consortia model (if time)
  • Backlog:
    • Potential item: is OKAPI-241 a topic for the TC backlog? Description fields in JSON schemas are useful documentation and there is potential to use the  to generate data dictionaries.

Discussion items

TimeItemWhoNotes
5minAssign notetakerZak Burke
10minHard-coded lists

Jakub Skoczen

PC recording from 2018-08-09, discussion spans15:02-25:28

  • folks at Stacks (who are doing the dev work) and Ann-Marie Breaux (Deactivated) (from the related SIG) are discussing the current implementation; hard-coding lists was a deliberate choice at the time.
  • we do have a generic UI component for maintaining "controlled vocab" lists though data-storage is module-local
  • Ian Ibbotson (Use this one) notes it would be great to link to live examples from the Ansible Playbook
  • Jakub Skoczen will coordinate doc updates with David Crossley
20minAES discussion (followup on out-of-band discussions)

VBar

Okapi Asynchronous Event Service (AES) DRAFT

  • goal is a detailed-enough proposal that we can establish features and expectations without requiring a specific implementation, i.e. a publication/subscription service that generates events we can feed to a message-queue such as Kakfa or RabbitMQ
  • current assumptions
    • system is built into Okapi; source of a message is Okapi itself, not an individual module
    • message producers are implicit: Okapi will capture data, produce messages
    • message consumers are explicit: could be other modules, could be completely external systems
  • VBar will continue to refine this document in preparation for formal RFC
30minWorkflow

Ian Ibbotson (Use this one)?

  • there are some specific technical concerns about Camunda: how will it handle multi-tenant interactions; what does its concept of a "user" mean in the context of use by Folio?
  • consensus that we need detailed use-cases to move ahead with evaluation of any particular solution; probably we can only get that by assigning a PO, an architect/senior dev, maybe (probably) some time from devops to fill out the backlog for a meaningful proof-of-concept implementation
  • Tod Olson will confer with Mike Gorrell to whack out a rough proposal to PC within the next week or two
20minConsortia model
did not discuss; pushed to backlog
5minBacklog and action items

OKAPI-241, use description field in JSON schemas

  • consensus: probably this is good policy; first set policy and add to documentation (Jakub Skoczen will ask David Crossley), then can become an execution task for teams

Action items