<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dear OpenStack community,<br class=""><br class=""><br class="">The short version: We are proposing a new set of use cases for OpenStack and a set of<br class="">changes to enable a multi-landlord cloud model, where multiple service<br class="">providers can cooperate (and compete) to stand up services in a single<br class="">cloud. We had great feedback from the community in the summit, and<br class="">came away with two strong messages: 1) this is a radical enough change<br class="">that we should do an end-to-end proof of concept, and 2) we should<br class="">post to this list what we are doing to make it visible to the broader<br class="">developer community; fully solving the problems of a multi-landlord<br class="">cloud will impact more projects than we understand today. We hope to<br class="">have available prototypes of the key enabling changes by the keystone<br class="">mid-cycle and an end-to-end demo by the Tokyo summit. <br class=""><br class="">Two additional points: <br class=""><br class=""> 1. Solving the problems of landlords that don't trust each other<br class=""> also brings defense in depth for a single provider cloud;<br class=""> potentially preventing an exploit of one service from<br class=""> compromising an entire cloud.<br class=""><br class=""> 2. This work strongly relates to resource federation work that is<br class=""> ongoing in OpenStack, and is complementary to, and being persued<br class=""> in the context of the recently annouced Mercador project.<br class=""><br class="">We, of course, welcome participating by other developers interested in<br class="">working with us on this through the Mercador project or by contacting<br class="">us as per info below.<br class=""><br class="">The long version:<br class="">----------------------<br class=""><br class="">All current clouds are stood up by a single company or organization,<br class="">creating a vertically integrated monopoly. Any competition is between<br class="">entire clouds and is limited by the customer's ability to move their<br class="">data over the connectivity between clouds. We think an alternative<br class="">model is possible, where different organizations can stand up<br class="">individual services in the same data centers, and the customer (or<br class="">intermediaries acting on their behalf) can pick and choose between<br class="">them. We call this model of having multiple landlords in a cloud an<br class="">Open Cloud eXchange (OCX)<br class="">(<a href="http://www.cs.bu.edu/fac/best/res/papers/ic14.pdf" class="">http://www.cs.bu.edu/fac/best/res/papers/ic14.pdf</a>).<br class=""><br class="">The OCX model would enable more innovation by technology companies,<br class="">enable cloud research and provide more choice to cloud consumers. We<br class="">are developing this model in a new public cloud, the Massachusetts<br class="">Open Cloud (MOC), that is just being started in the MGHPCC data center<br class="">(<a href="http://www.mghpcc.org/" class="">http://www.mghpcc.org</a>) shared between Boston University, Harvard<br class="">University, the Massachusetts Institute of Technology, Northeastern<br class="">University, and the University of Massachusetts. Some use cases being<br class="">explored in the context of the MOC illustrate the potential of this<br class="">model:<br class=""><br class="">o Harvard and MIT both stand up their own OpenStack cloud for<br class=""> students, but provide resources on-demand to the MOC that can be used<br class=""> by researchers that collaborate between the universities and by<br class=""> external users. <br class="">o A storage company stands up a new innovative block storage service<br class=""> on a few racks in the MGHPCC, operates it themselves, and makes it<br class=""> available to users of the MOC and/or the individual university<br class=""> clouds. The storage company is in total control of price,<br class=""> automation, and SLA for the service, and users can choose if they<br class=""> want to use the service.<br class="">o A company stands up a new compute service with innovative hardware<br class=""> (e.g., FPGAs, crypto accellerator) or pricing model. A customer<br class=""> with a two Petabyte disk volume can switch to using that compute<br class=""> without having to move the data.<br class="">o A research group at Boston University and Northeastern develops a<br class=""> highly elastic compute service that can checkpoint 1000s of servers<br class=""> in seconds into SSD, and broadcast provision a distributed<br class=""> application to allow an interactive medical imaging application that<br class=""> wants 1000s of servers for a few seconds. <br class="">o A security sensitive life sciences company exploits software from<br class=""> the MACS project (<a href="http://www.bu.edu/hic/research/macs/" class="">http://www.bu.edu/hic/research/macs/</a>) to<br class=""> distribute their data across two storage services from non-colluding<br class=""> providers. The data is accessed from a Nova compute service running<br class=""> on a trusted compute platform developed collaboratively with<br class=""> Intel. Since all services are deployed in the same datacenter, the<br class=""> computation is efficient.<br class="">o Students in a cloud computing course offered by Northeastern and<br class=""> Boston University faculty<br class=""> (<a href="https://okrieg.github.io/EC500/index.html" class="">https://okrieg.github.io/EC500/index.html</a>) develop and stand up an<br class=""> experimental proxy service for open stack services that provides<br class=""> users of the MOC a Swift service that combines the inventory of<br class=""> multiple underlying Swift services.<br class=""><br class="">While no existing cloud stack can support the OCX model out of the<br class="">box, OpenStack is much closer than anything else, and we have been<br class="">exploring what changes will be required to enable this model<br class="">(<a href="http://open.bu.edu/handle/2144/11214" class="">http://open.bu.edu/handle/2144/11214</a>) and worked with our partners<br class="">in the community to submit a number of (now dated) blueprints to<br class="">handle our new use cases:<br class=""> o <a href="https://review.openstack.org/#/c/123782" class="">https://review.openstack.org/#/c/123782</a><br class=""> o <a href="https://review.openstack.org/#/c/132623" class="">https://review.openstack.org/#/c/132623</a><br class=""> o <a href="https://review.openstack.org/#/c/123726" class="">https://review.openstack.org/#/c/123726</a><br class=""><br class="">We believe solutions to the problems of the OCX model will improve<br class="">OpenStack generally from a security and reliability<br class="">perspective. Solving the problems of multiple providers/landlords that<br class="">don't trust each other also brings defense in depth for a single<br class="">provider cloud; potentially preventing an exploit of one service from<br class="">compromising an entire cloud.<br class=""><br class="">We first described the idea of an OCX in the Atlanta summit<br class="">(<a href="https://www.youtube.com/watch?v=yuUb7XWnOcw" class="">https://www.youtube.com/watch?v=yuUb7XWnOcw</a>) and the MOC project was<br class="">funded in December of 2014. At the OpenStack summit in Vancouver we<br class="">had the amazing experience of the community embracing the idea, and<br class="">helping to educate us on much better solutions for the use cases. For<br class="">example, based on the conversations we now have a scheme to build the<br class="">federated authorization on top of the recent federated authentication<br class="">capabilities of Keystone. Also, we will be modifying Horizon rather<br class="">than developing a new UI. We will, of course, be updating the<br class="">blueprints and developing specs.<br class=""><br class="">We wanted to send out this note for three reasons. First, we wanted<br class="">to thank the community for all the feedback we got in the summit. We<br class="">were blown away by how open you are to new ideas & problems and your<br class="">patience in educating new members when we propose dumb solutions :).<br class="">Second, we had the strong advice from a number of developers that we<br class="">should send a note to this list letting a broader audience know about<br class="">the project; decisions are being made by many different groups that<br class="">will make the model more or less practical, and we understand that its<br class="">important to get the new use cases out there. Third, we wanted to<br class="">announce that based on all the feedback we think we (who are a larger<br class="">team than before the summit :) now have a clear path to a<br class="">prototype. We hope to have available prototypes of many key enabling<br class="">changes by mid-cycle and an end-to-end demo by the Tokyo summit. We<br class="">will be doing this work in the context of the newly annouced Mercador<br class="">project <<a href="https://wiki.openstack.org/wiki/Mercador" class="">https://wiki.openstack.org/wiki/Mercador</a>>. The Mercador<br class="">focus was originally on federation of resourcs between untrusting<br class="">single provider clouds. When the two teams met at the summit, we<br class="">realized that the two projects solve orthogonal but complementary<br class="">problems, and we decided by joining forces we can help ensure that the<br class="">(still orthogonal) development efforts don't come up with solutions<br class="">that are incompatible.<br class=""><br class="">Thanks again, it was an awesome experience meeting many of you in<br class="">Vancouver.<br class=""> -- the MOC/OCX gang ++<br class=""><br class="">web: <a href="http://massopencloud.org/" class="">http://massopencloud.org</a><br class="">email: <a href="mailto:moc-team-list@bu.edu" class="">moc-team-list@bu.edu</a><br class="">irc: #moc on freenode</body></html>