Open Stack

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 <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
>> <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
>
>
>
> __________________________________________________________________________
> 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,

Matt Riedemann