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,
Peng
------------------ Original ------------------
From: "Adrian Otto"<adrian.o...@rackspace.com>;
Date: Mon, Jul 27, 2015 12:43 PM
To: "OpenStack Development Mailing List (not for usage
questions)"<openstack-dev@lists.openstack.org>;
Subject: Re: [openstack-dev] Announcing HyperStack project
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 <p...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
