[openstack-dev] Announcing HyperStack project

Peng Zhao peng at hyper.sh
Mon Jul 27 11:53:52 UTC 2015

Adrian and all,

I believe that Magnum and HyperStack are targeting at different problems, though it certainly makes sense to integrate HyperStack as a bay type in Magnum, which we would love to explore later. I've setup a separate project for HyperStack: https://launchpad.net/hyperstack. My apology for the confusion.

I understand the concern of duplicating Nova and others. But imagine a vision that application can seamlessly migrate or scale out/in between LXC-based private CaaS and Hypervisor-based public CaaS, without the need to pre-build a bay. 

This ultimate portability & simplicity simply overweighs the rest!

HyperStack advocates the true multi-tenant, secure, public CaaS, which is really the first one and is built within OpenStack framework. I think HyperStack provides a seamless and probably the best path to upgrade to the container era.

For the team meeting, it is sometime very late for me (2am Beijing). I'll try to join more and look forward to speak with you and others in person.

Sorry again for the misunderstanding,

------------------ Original ------------------
From:  "Adrian Otto"<adrian.otto at rackspace.com>;
Date:  Mon, Jul 27, 2015 12:43 PM
To:  "OpenStack Development Mailing List (not for usage questions)"<openstack-dev at lists.openstack.org>; 

Subject:  Re: [openstack-dev] Announcing HyperStack project

 For the record, the Magnum team is not yet comfortable with this proposal. This arrangement is not the way we think containers should be integrated with OpenStack. It completely bypasses Nova, and offers no Bay abstraction, so there is no user  selectable choice of a COE (Container Orchestration Engine). We advised that it would be smarter to build a nova virt driver for Hyper, and integrate that with Magnum so that it could work with all the different bay types. It also produces a situation where  operators can not effectively bill for the services that are in use by the consumers, there is no sensible infrastructure layer capacity management (scheduler), no encryption management solution for the communication between k8s minions/nodes and the k8s master,  and a number of other weaknesses. I’m not convinced the single-tenant approach here makes sense. 
 To be fair, the concept is interesting, and we are discussing how it could be integrated with Magnum. It’s appropriate for experimentation, but I would not characterize it as a “solution for cloud providers” for the above reasons, and the callouts  I mentioned here:
 Positioning it that way is simply premature. I strongly suggest that you attend the Magnum team meetings, and work through these concerns as we had Hyper on the agenda last Tuesday, but you did not show up to discuss it. The ML thread was confused  by duplicate responses, which makes it rather hard to follow.
 I think it’s a really bad idea to basically re-implement Nova in Hyper. Your’e already re-implementing Docker in Hyper. With a scope that’s too wide, you won’t be able to keep up with the rapid changes in these projects, and anyone using them  will be unable to use new features that they would expect from Docker and Nova while you are busy copying all of that functionality each time new features are added. I think there’s a better approach available that does not require you to duplicate such a  wide range of functionality. I suggest we work together on this, and select an approach that sets you up for success, and gives OpenStack could operators what they need to build services on Hyper.
   On Jul 26, 2015, at 7:40 PM, Peng Zhao <peng at hyper.sh> wrote:
    Hi all,
  I am glad to introduce the HyperStack project to you.
  HyperStack is a native, multi-tenant CaaS solution built on top of OpenStack. In terms of architecture, HyperStack = Bare-metal + Hyper + Kubernetes + Cinder + Neutron.
  HyperStack is different from Magnum in that HyperStack doesn't employ the Bay concept. Instead, HyperStack pools all bare-metal servers into one singe cluster. Due to the hypervisor nature in Hyper, different tenants' applications are completely isolated (no  shared kernel), thus co-exist without security concerns in a same cluster.
  Given this, HyperStack is a solution for public cloud providers who want to offer the secure, multi-tenant CaaS.
  Ref:  https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/1258x535/1c85a755dcb5e4a4147d37e6aa22fd40/upload_7_23_2015_at_11_00_41_AM.png
  The next step is to present a working beta of HyperStack at Tokyo summit, which we submitted a presentation: https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/4030.  Please vote if you are interested.
  In the future, we want to integrate HyperStack with Magnum and Nova to make sure one OpenStack deployment can offer both IaaS and native CaaS services.
  ---------- Background ---------------------------------------------------------------------------
  Hyper is a hypervisor-agnostic Docker runtime. It allows to run Docker images with any hypervisor (KVM,  Xen, Vbox, ESX). Hyper is different from the minimalist Linux distros like CoreOS by that Hyper runs on the physical box and load the Docker images from the metal into the VM instance, in which no guest OS is present. Instead, Hyper boots a minimalist kernel  in the VM to host the Docker images (Pod).
  With this approach, Hyper is able to bring some encouraging results, which are similar to container:
 - 300ms to boot a new HyperVM instance with a pod of Docker images
 - 20MB for min mem footprint of a HyperVM instance
 - Immutable HyperVM, only kernel+images, serves as atomic unit (Pod) for scheduling
 - Immune from the shared kernel problem in LXC, isolated by VM
 - Work seamlessly with OpenStack components, Neutron, Cinder, due to the hypervisor nature
 - BYOK, bring-your-own-kernel is somewhat mandatory for a public cloud platform
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:  OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150727/6d0d9ebf/attachment.html>

More information about the OpenStack-dev mailing list