- Kick tires for stakeholders – a demo space
- iSchool pilot
- catalog to have Data
- anticipated features (based on phenome2017 experience)
- Shared data between accounts
- Authentication that is tied into the academic system
- Ensure that services are tested and operational before needed in the class
- Will need to manually update instance weekly adding the new service and removing the old service
- Support for the students (may require 24-hour support)
- We should try to include auto shutting down instances (need to determine what is means to be “active” and then the number of hours of inactivity)
- Start the end of March
- Upcoming Sprint Priorities
- iSchool anticipation
- shared data
- Documentation (ReadMe, Labs website page, etc.)
- Concrete things that can be done in setting up for the iSchool:
- Could add auditing (who did what, how many people did what, how long, etc.)
- Set-up to run multiple of these iSchool instances on the same cluster (VM)
- Ability to deploy on other environments (like AWS)
- Failover
- What about backups? Just keep a live copy.
- Mount a shared data volume (replacement for tool server in TERRA)
- OAuth and user management
- design and requirements
- Ability to scale up and down
- Without losing data or audit trail
- Support plan
- Updated Test Plans
- Security analysis for Docker containers
- We should regularly audit
- DataDNS architecture diagrams with high-level tasks and identify components others would work on:
- Work package one: Dataset Crawler
Work package two: Analysis tool
- Work package one: Dataset Crawler
- NDSC7 demo planning
- iSchool anticipation
Page History
Overview
Content Tools