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