On 7/26/2015 11:43 PM, Adrian Otto wrote:
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
The nova-hyper virt driver idea has already been proposed:
http://lists.openstack.org/pipermail/openstack-dev/2015-June/067501.html
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
<mailto: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
<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
<mailto: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
--
Thanks,
Matt Riedemann
__________________________________________________________________________
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
