<div dir="ltr">Hi Orran, <div><br></div><div>We also have a project called Tricircle that aim to solve similar problem, but with a different approach with <span style="font-size:12.8000001907349px">Mercador. You and your team are more than welcome to join the discussion we will hold in Tricircle Meeting.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">See the details at <a href="https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg54861.html">https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg54861.html</a>, and <a href="https://github.com/stackforge/tricircle">https://github.com/stackforge/tricircle</a> , and also our PoC results <a href="http://www.slideshare.net/JoeHuang7/test-report-for-open-stack-cascading-solution-to-support-1-million-v-ms-in-100-data-centers">http://www.slideshare.net/JoeHuang7/test-report-for-open-stack-cascading-solution-to-support-1-million-v-ms-in-100-data-centers</a> :)</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Hope you guys find it helpful.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 10, 2015 at 9:37 PM, Orran Krieger <span dir="ltr"><<a href="mailto:okrieg@gmail.com" target="_blank">okrieg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Dear OpenStack community,<br><br><br>The short version: We are proposing a new set of use cases for OpenStack and a set of<br>changes to enable a multi-landlord cloud model, where multiple service<br>providers can cooperate (and compete) to stand up services in a single<br>cloud. We had great feedback from the community in the summit, and<br>came away with two strong messages: 1) this is a radical enough change<br>that we should do an end-to-end proof of concept, and 2) we should<br>post to this list what we are doing to make it visible to the broader<br>developer community; fully solving the problems of a multi-landlord<br>cloud will impact more projects than we understand today. We hope to<br>have available prototypes of the key enabling changes by the keystone<br>mid-cycle and an end-to-end demo by the Tokyo summit.  <br><br>Two additional points: <br><br> 1. Solving the problems of landlords that don't trust each other<br>    also brings defense in depth for a single provider cloud;<br>    potentially preventing an exploit of one service from<br>    compromising an entire cloud.<br><br> 2. This work strongly relates to resource federation work that is<br>    ongoing in OpenStack, and is complementary to, and being persued<br>    in the context of the recently annouced Mercador project.<br><br>We, of course, welcome participating by other developers interested in<br>working with us on this through the Mercador project or by contacting<br>us as per info below.<br><br>The long version:<br>----------------------<br><br>All current clouds are stood up by a single company or organization,<br>creating a vertically integrated monopoly.  Any competition is between<br>entire clouds and is limited by the customer's ability to move their<br>data over the connectivity between clouds.  We think an alternative<br>model is possible, where different organizations can stand up<br>individual services in the same data centers, and the customer (or<br>intermediaries acting on their behalf) can pick and choose between<br>them.  We call this model of having multiple landlords in a cloud an<br>Open Cloud eXchange (OCX)<br>(<a href="http://www.cs.bu.edu/fac/best/res/papers/ic14.pdf" target="_blank">http://www.cs.bu.edu/fac/best/res/papers/ic14.pdf</a>).<br><br>The OCX model would enable more innovation by technology companies,<br>enable cloud research and provide more choice to cloud consumers. We<br>are developing this model in a new public cloud, the Massachusetts<br>Open Cloud (MOC), that is just being started in the MGHPCC data center<br>(<a href="http://www.mghpcc.org/" target="_blank">http://www.mghpcc.org</a>) shared between Boston University, Harvard<br>University, the Massachusetts Institute of Technology, Northeastern<br>University, and the University of Massachusetts.  Some use cases being<br>explored in the context of the MOC illustrate the potential of this<br>model:<br><br>o Harvard and MIT both stand up their own OpenStack cloud for<br> students, but provide resources on-demand to the MOC that can be used<br> by researchers that collaborate between the universities and by<br> external users.  <br>o A storage company stands up a new innovative block storage service<br> on a few racks in the MGHPCC, operates it themselves, and makes it<br> available to users of the MOC and/or the individual university<br> clouds.  The storage company is in total control of price,<br> automation, and SLA for the service, and users can choose if they<br> want to use the service.<br>o A company stands up a new compute service with innovative hardware<br> (e.g., FPGAs, crypto accellerator) or pricing model.  A customer<br> with a two Petabyte disk volume can switch to using that compute<br> without having to move the data.<br>o A research group at Boston University and Northeastern develops a<br> highly elastic compute service that can checkpoint 1000s of servers<br> in seconds into SSD, and broadcast provision a distributed<br> application to allow an interactive medical imaging application that<br> wants 1000s of servers for a few seconds. <br>o A security sensitive life sciences company exploits software from<br> the MACS project (<a href="http://www.bu.edu/hic/research/macs/" target="_blank">http://www.bu.edu/hic/research/macs/</a>) to<br> distribute their data across two storage services from non-colluding<br> providers.  The data is accessed from a Nova compute service running<br> on a trusted compute platform developed collaboratively with<br> Intel. Since all services are deployed in the same datacenter, the<br> computation is efficient.<br>o Students in a cloud computing course offered by Northeastern and<br> Boston University faculty<br> (<a href="https://okrieg.github.io/EC500/index.html" target="_blank">https://okrieg.github.io/EC500/index.html</a>) develop and stand up an<br> experimental proxy service for open stack services that provides<br> users of the MOC a Swift service that combines the inventory of<br> multiple underlying Swift services.<br><br>While no existing cloud stack can support the OCX model out of the<br>box, OpenStack is much closer than anything else, and we have been<br>exploring what changes will be required to enable this model<br>(<a href="http://open.bu.edu/handle/2144/11214" target="_blank">http://open.bu.edu/handle/2144/11214</a>) and worked with our partners<br>in the community to submit a number of (now dated) blueprints to<br>handle our new use cases:<br> o <a href="https://review.openstack.org/#/c/123782" target="_blank">https://review.openstack.org/#/c/123782</a><br> o <a href="https://review.openstack.org/#/c/132623" target="_blank">https://review.openstack.org/#/c/132623</a><br> o <a href="https://review.openstack.org/#/c/123726" target="_blank">https://review.openstack.org/#/c/123726</a><br><br>We believe solutions to the problems of the OCX model will improve<br>OpenStack generally from a security and reliability<br>perspective. Solving the problems of multiple providers/landlords that<br>don't trust each other also brings defense in depth for a single<br>provider cloud; potentially preventing an exploit of one service from<br>compromising an entire cloud.<br><br>We first described the idea of an OCX in the Atlanta summit<br>(<a href="https://www.youtube.com/watch?v=yuUb7XWnOcw" target="_blank">https://www.youtube.com/watch?v=yuUb7XWnOcw</a>) and the MOC project was<br>funded in December of 2014.  At the OpenStack summit in Vancouver we<br>had the amazing experience of the community embracing the idea, and<br>helping to educate us on much better solutions for the use cases.  For<br>example, based on the conversations we now have a scheme to build the<br>federated authorization on top of the recent federated authentication<br>capabilities of Keystone.  Also, we will be modifying Horizon rather<br>than developing a new UI. We will, of course, be updating the<br>blueprints and developing specs.<br><br>We wanted to send out this note for three reasons.  First, we wanted<br>to thank the community for all the feedback we got in the summit. We<br>were blown away by how open you are to new ideas & problems and your<br>patience in educating new members when we propose dumb solutions :).<br>Second, we had the strong advice from a number of developers that we<br>should send a note to this list letting a broader audience know about<br>the project; decisions are being made by many different groups that<br>will make the model more or less practical, and we understand that its<br>important to get the new use cases out there.  Third, we wanted to<br>announce that based on all the feedback we think we (who are a larger<br>team than before the summit :) now have a clear path to a<br>prototype. We hope to have available prototypes of many key enabling<br>changes by mid-cycle and an end-to-end demo by the Tokyo summit.  We<br>will be doing this work in the context of the newly annouced Mercador<br>project <<a href="https://wiki.openstack.org/wiki/Mercador" target="_blank">https://wiki.openstack.org/wiki/Mercador</a>>.  The Mercador<br>focus was originally on federation of resourcs between untrusting<br>single provider clouds.  When the two teams met at the summit, we<br>realized that the two projects solve orthogonal but complementary<br>problems, and we decided by joining forces we can help ensure that the<br>(still orthogonal) development efforts don't come up with solutions<br>that are incompatible.<br><br>Thanks again, it was an awesome experience meeting many of you in<br>Vancouver.<br>   -- the MOC/OCX gang ++<br><br>web:   <a href="http://massopencloud.org/" target="_blank">http://massopencloud.org</a><br>email: <a href="mailto:moc-team-list@bu.edu" target="_blank">moc-team-list@bu.edu</a><br>irc:   #moc on freenode</div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Zhipeng (Howard) Huang</div><div dir="ltr"><br></div><div dir="ltr">Standard Engineer</div><div>IT Standard & Patent/IT Prooduct Line</div><div dir="ltr">Huawei Technologies Co,. Ltd</div><div dir="ltr">Email: <a href="mailto:huangzhipeng@huawei.com" target="_blank">huangzhipeng@huawei.com</a></div><div dir="ltr">Office: Huawei Industrial Base, Longgang, Shenzhen</div><div dir="ltr"><br></div><div dir="ltr">(Previous)<br><div>Research Assistant</div><div>Mobile Ad-Hoc Network Lab, Calit2</div><div>University of California, Irvine</div><div>Email: <a href="mailto:zhipengh@uci.edu" target="_blank">zhipengh@uci.edu</a></div><div>Office: Calit2 Building Room 2402</div><div><br></div><div>OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado</div></div></div></div></div></div></div>
</div>