Open Stack

Peng,

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:

http://lists.openstack.org/pipermail/openstack-dev/2015-July/069940.html

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.

Regards,

Adrian

On Jul 26, 2015, at 7:40 PM, Peng Zhao <peng at hyper.sh<mailto: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.
Best,
Peng
---------- 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<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150727/2176b143/attachment.html>