Open Stack

Thanks Matt, though proposed but nova team think that this should belong to
Magnum ;-) We can check where is the best place for hyper.

2015-07-27 16:06 GMT-04:00 Matt Riedemann <mriedem at linux.vnet.ibm.com>:

>
>
> 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
>
>
> __________________________________________________________________________
> 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/20150728/a708f803/attachment.html>