...
- 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.