Child pages
  • VM library and gateway hosting breakout agenda and minutes
Skip to end of metadata
Go to start of metadata

Related topics initiated by several conversations:

  • Craig Stewart (need to describe what SPs offer to gateways)
  • Shawn Strande (need to represent the fact that XSEDE provides gateway hosting)
  • ECSS project request from PI Adam Brazier (Cornell) for a cross-XSEDE VM library
  • email from Marlon after a Bridges presentation suggesting integration of gateway resources at a higher level, e.g.  Amazon regions and availability zones or gateway-level scheduling

We will discuss how these needs overlap, discuss what has already been accomplished, decide what we would like to do to move forward and outline and assign next steps.



  • 2/2/17 email from Craig Stewart to 

    J. Ray Scott <>; Nick Nystrom <>;Nancy Wilkins-Diehr <>; Hancock, David Y<>; Fischer, Jeremy <>; Strande, Shawn <>

    "I think we all have in our heads a mental view of what sorts of science gateways are best served by comet, bridges, and Jetstream. However, there is nothing available in the documentation for users on the different systems that allows them to easily distinguish when making resource requests. I¹d like to propose that we write a paragraph per system of factual information that will inform user decisions. For example, I will write that Comet and Bridges are both better suited than Jetstream for hosting science gateways that require large amounts of memory. If this seems a good idea, could each of us send 1 paragraph about a system to, our excellent editor (Dr. Winona Snapp) will edit and assemble them, and post them in a google doc (or send them out) for joint review. I¹d like to have as a goal a posting of this information by 1 March, so that it can inform the next round of allocation requests.

  • 1/12/17 email from Nancy to Ron and Laura requesting this meeting

"Marlon and I would like to propose a breakout session for the March quarterly.  We recently received an ESSGW request from PI Adam Brazier (Cornell) on Jetstream and Wrangler where one of the activities is for assistance developing a VM library [1]. While this isn’t a typical ESSGW project, it could be something of value XSEDE-wide (especially with several resources offering virtualization). On a related front we’ve recently heard from an SP that gateway hosting is not well-advertised on the website.

We feel that moving forward on these issues would involve others in XSEDE (User Services) and SPs as well. As a first step, we’d like to schedule a breakout in March. If you could schedule something, we’ll then send a note to the SMT with the background and an invitation to join. We will likely have to involve SPs in a subsequent meeting since not all representatives attend the quarterlies. If we schedule this early enough, it’s possible that some may be able to stay past the XRAC.

[1] Activities such as project Aristotle and the Supercloud project beg for the existence of a VM repository, something that XSEDE has already been discussing. As part of our application we are requesting ECSS (XSEDE Extended Collaborative Support Services) effort to begin developing such a library at small scale. The obvious intersection of cloud interoperability and XSEDE science gateway technology is to create gateways that have the capability of opportunistically directing jobs to various cloud resource providers; with XSEDE staff assistance, we will implement at least one use case as a science gateway."

  • 11/1/16 email from Marlon to Bridges team after their presentation to SGCI

"Bridges does provide hosting, and the PSC team has been pretty active about recruiting gateways. I have an XSEDE ECSS call this morning with one.  As with Comet and Jetstream (but in differing ways), Bridges provides some powerful integrated gateway capabilities for hosting, storage, and computing.

I would personally like to see ways for these three XSEDE resources become integrated at a higher level.  One analogy could be with Amazon regions and availability zones, and another is the possibility of gateway-level scheduling."

  • No labels