Dial In Details
Date: Wednesday, October 28 2015 at 3PM EDT (-4 UTC)
Dial-in Number: (712) 775-7035
- Participant Code: 479307#
- Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
Meeting Goals
Participant’s roles and commitments
Development process
- Define scope
Review of collected use cases and requirements
Define timeline and milestones (what can be accomplished and when)
Attendees
- Randall Floyd
- William G. Cowan
- Andrew Woods
- Bethany Seeger
- Brad Spry
- John Rees
- Aaron Birkland
- Yinlin Chen
- Don Brower
- Nick Ruest
Agenda
Introduction and review of meeting goals
Roles and commitments
Identify Stakeholders, Designers, Developers
Development processes
Sprint cycles and duration
Communication modes
- Process for consensus on use cases, scope, and requirements
High-level design and implementation discussion
- Review of existing design discussions
Likely use of API Extension Architecture
Mediated asynchronous services vs. pluggable storage
- Review of existing design discussions
Review existing use cases
Are they adequately described?
Do we have all the use cases we need or want? Are there more?
- Discussion of scope
- Timelines and milestones
Related Resources
- Design - Asynchronous and Pluggable Storage
- Meeting notes: 2015-08-17 - Indiana - Amherst F4 Storage
- Design - API Extension Architecture
Meeting Notes
- Round table of intros
- Roles and commitments
- IU (Randall and William) committed to lead and provide significant developer time
- UNC-Charlotte (Brad) stakeholder, QA over AWS testing
- Duraspace (Andrew) wrangler/encourager, feedback offeror
- NLM (Rees) stakeholder/lurker, contribute case studies
- Notre dame (Don) stakeholder, contribute use cases, perhaps some developer time
- Va Tech (Yinlin) stakeholder, cold storage use case, AWS testing
- Nick R. (role with Ontario cloud service) –stakeholder, tester, perhaps some development
- Amrherst (Bethany/Aaron) stakeholder, Aaron has a Glacier cold storage interest, not sure about commitment level
General agreement that we'd all like to better understand ties with the API-X effort/group. We should try to cross-pollinate, communicate, understand/identify synergies where they exist, but at a distance, too.
- Process
- Assume work will progress under an Agile framework, with development sprints
- still need significant time to gain a shared understanding before scheduling any work
- expect user stories/context and development work will progress asynchronously
- High-level design
- Existing use cases/design discussions -- are old but still hold relevance and resonate for many at a high level
- API extension architecture – relationship with API-X/F4 extension architecture could be strengthened, but agree it is a suitable framework to start but will likely evolve as requirements emerge
- Woods emphasizes F4's slim code core philosophy
- Why asynch storage not core? Aaron B. some interactions with specific storage options may need more direct integration with F4 core, but other pieces of a plugable API may not; requirement details should start to reveal these divergences
- Mediated services vs. plugable storage – related to API-X. Randall making a distinction between the heavy lifting needed by any storage solution vs. F4 REST services/messaging interactions
- Use cases
- Aaron–API-X experience demonstrated that use cases generally need some common structure and better task/outcome definitions to properly generate evaluation criteria
- Action items:
- Randall will look at API-X templates as inspiration to create some for this group
- Attendees will look at current use cases with a fresh eye to ensure their needs are being met; Woods encourages use of the wiki's 'like' feature for lurkers or the uncommitted so at least your voice is recorded–it matters
Sidebar: Randy asks if perhaps Brad has already done some of this plumbing with S3?
Brad: yes, in F3 for datastreams, but other data types need other tools. Employs S3fs FUSE -- mounts Linux filesystem to S3 buckets https://github.com/s3fs-fuse/s3fs-fuse.
Some I/O transactions too fast, such as with triplestore. Block sizes matter–issue is how to fine tune Fedora in this regard
7. Timelines and milestones
- Expectation is no development sprints until 2016
- Also have potential dependency on API-X development schedule
Meeting schedule: every two weeks, same day/time, to keep the ball rolling
Complete action items from #5 by next meeting.