Open Stack

Thanks Adrian, we can talk later in the IRC meeting.

2015-07-28 4:07 GMT-04:00 Adrian Otto <adrian.otto at rackspace.com>:

>  Jay,
>
>  Yes, it is on the agenda.
>
>  Thanks,
>
>  Adrian
>
>  On Jul 27, 2015, at 8:32 AM, Jay Lau <jay.lau.513 at gmail.com> wrote:
>
>   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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>   Thanks,
>
>  Jay Lau (Guangya Liu)
>
> __________________________________________________________________________
> 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/20150728/e8b6a8bb/attachment.html>