Skip to end of metadata
Go to start of metadata


Topic 1: Advertising Gateway Hosting QMA-170 - Getting issue details... STATUS Concise information on Comet, Bridges, and Jetstream hosting should be available on the XSEDE portal. Gateways should be listed as a top level request resource at .
Topic 2: Sharable XSEDE VM/Container Libraries QMA-171 - Getting issue details... STATUS This work is closely related to a Project Improvement Fund (PIF) request, and the scope if very large. It was decided to await the outcome of PIF decisions and to also investigate NSF funding.

Action Items:

SummaryDescriptionResponsibleDue Date
Gateway Documentation (Topic 1) QMA-172 - Getting issue details... STATUS Provide concise descriptions of XSEDE resourcesMarlon Pierce with help from Comet, Bridges and Jetstream providers (build on previous work by Craig Stewart) 
Web Site (Topic 1) QMA-173 - Getting issue details... STATUS Provide a clear link on the XSEDE Web site resources page identifying Gateways.Maytal Dahan 
RDR Upgrades (Topic 1) QMA-174 - Getting issue details... STATUS Add gateway-centric descriptions and fields to RDR descriptions of Comet, Jetstream, and Bridges. Integrate this with the XSEDE web site.JP Navarro, Maytal Dahan 
Investigate Potential VM/Container Library Funding (Topic 2) QMA-175 - Getting issue details... STATUS Consult with NSF to see if this is separately fundable work and identify the correct solicitation or mechanism.David Lifka (question) 


Topic 1: Make it more obvious that PIs can request gateway hosting from XSEDE and make it clear which resources are appropriate

  • No obvious way to request gateway hosting resources.

  • SPs for Comet, Jetstream, etc wrote some short text in Google Docs. But it isn’t appropriate for the portal, needs to be simplified, displayed as tables, etc

    • Need Wrangler and Bridges text

  • Emre: suggests use the term “cloud”

  • Dan Z: are you just talking about VMs that host servers, or are you talking also about gateway support for backend support

  • Maytal: Does RDR have a way to highlight how they can be used by gateways?

    • This will show up in the popup when selecting a machine.

  • Tie this to the revised Gateway documentation pages.

  • Sergiu: gateways could mention how they use gateways.

    • Where they are hosted and which machines do they use?

  • Victor: in the RDR there is no field that says a resource is adept at running a gateway job

    • Various other discussions of how to put information in the RDR to help gateways

    • May want to add the “cloud” type that is similar to the HPC, HTC, Viz, etc fields.

  • Maytal: would like to have gateway-specific fields for the RDF

  • Conclusion:

Topic 2: VM Libraries

  • ECSS request about a cross-platform library

  • Rich K: project to set up libraries for Jetstream but have also submitted a PIF.

    • Exchange at least between Jetstream and Bridges

    • Dan Z: already discussed on the SP Forum

    • Cloud-init may allow this to work on other platforms as well.

    • Dan Z: also have a VMWare-based VM hosting system at TACC for gateways, and Wrangler can potentially host gateways.

  • Dan Z: containerization will also drive this. Singularity gaining traction.

  • Nick: agreed, assume the VM library will evolve into a container library.

    • Need to think of a vetting process for user-submitted VMs/containers

    • There are already repositories out there, so federate rather than duplicate.

  • Rich: PIF discussions led to thoughts of going to the NSF to go further.  Use XSEDE as a launching pad.

  • JP: this is related to the software repository work.

  • Nancy: wait for the outcome of the PIF discussions.

  • JP: if PIF doesn’t go through, may have some margin for a small project.

  • Victor: this is a big project, many security and other issues to resolve, policies in different sites.

  • Lonnie: lots of solutions--docker, singularity, openstack, etc--is there some effort to centralize?

    • Nick: PSC is targeting singularity because of security and other concerns with docker.

  • Ralph: issue with a PIF is that this isn’t a 1 year project, so what happens after the first year?

    • Rich: PIF has a limited scope

    • Adam: but who will maintain the VMs and make updates?

    • JP: Service providers may have to inherit this.

  • Rich: the scope of the PIF is to create a set of instructions for creating VMs.

  • Victor: if singularity is the choice, then each of the SPs that participate would need to use this, support this.

  • Q: more like ansible?  Rich: yes, but using Heat libraries, etc

  • Victor: the PIF is a baby step. Should consider putting together a full proposal. Docker has many security issues, don’t see this as the right tool.

  • Rich: Dave Lifka was going to discuss with some NSF program officers.

  • Nancy: any good examples of this in the outside world?  

    • Rich: DockerHub

  • Adam: worry about the Appstore problem, reviewing code, etc. We don’t have the person power to do the reviewing.

    • Nick: what about a singularity container running in user space?

  • Nancy: we could have someone from singularity team to make a presentation to the security working group.

  • Conclusions:

    • Wait for PIF decisions

    • Pursue NSF funding


  • No labels