Notes from planning 1/20 meeting (Craig, David, Kandace, Mike)
We spent some time discussing the Workbench federation requirement.
Q. What is the benefit to the end user?
- It's unclear why a federated Workbench would be better for the end user than 3 separate instances
- Possible benefits:
- Because people will be operating on data at one site (not a current use case, since Workbench doesn't have data)
- Helps toward DataDNS architecture
- Failover when Nebula has problems
- Shows collaboration with NDSC, since there are already NDS resources at these sites
- Proximity to data and resources
- Specialized resources at each site (not a current use case, since we're not enabling access to any specialized resources)
- What are the risks
- increased operations
- increased complexity
- Failover is important, not federation at the moment
- Currently doesn't appear to be enough of a case to justify federation for workbench
Q. Should we focus on DataDNS?
- Federation makes more sense here
- More compelling to federate for DataDNS (fits DNS analogy, lack of a single point of failure)
- Extend current prototype
Q.Can we extend workbench to be useful to the scientist (e.g., Zuhone)
- Requires production support (long running, need to scale)
- Requires data support
- Scientists want to do science; they have to do this
- So we make it easy
Q. Build a federated infrastructure independent of Workbench
- Focus on federation with the goal of supporting workbench and DataDNS
- Same architecture
- Bigger than three data centers
- Ability to mix and match -- adapters for e.g., BW