Open Stack

Adrian,

Can we put hyper as a topic for this week's (Tomorrow) meeting? I want to
have some discussion with you.

Thanks

2015-07-27 0:43 GMT-04:00 Adrian Otto <adrian.otto at rackspace.com>:

>  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> 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?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,

Jay Lau (Guangya Liu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150727/51b264bb/attachment-0001.html>