subject:"\[openstack\-dev\] Announcing HyperStack project"

Re: [openstack-dev] Announcing HyperStack project

2015-07-28 Thread Jay Lau

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

2015-07-28 4:07 GMT-04:00 Adrian Otto :

>  Jay,
>
>  Yes, it is on the agenda.
>
>  Thanks,
>
>  Adrian
>
>  On Jul 27, 2015, at 8:32 AM, Jay Lau  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 :
>
>> 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  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

Re: [openstack-dev] Announcing HyperStack project

2015-07-28 Thread Jay Lau

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 :

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

Re: [openstack-dev] Announcing HyperStack project

2015-07-28 Thread Adrian Otto

Jay,

Yes, it is on the agenda.

Thanks,

Adrian

On Jul 27, 2015, at 8:32 AM, Jay Lau
mailto:jay.lau@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
mailto:adrian.o...@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 mailto:p...@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

___

Re: [openstack-dev] Announcing HyperStack project

2015-07-27 Thread Matt Riedemann

On 7/26/2015 11:43 PM, Adrian Otto wrote:

Peng,

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 mailto:p...@hyper.sh>> wrote:

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 Ma

Re: [openstack-dev] Announcing HyperStack project

2015-07-27 Thread Jay Lau

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 :

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

Re: [openstack-dev] Announcing HyperStack project

2015-07-27 Thread Peng Zhao

Adrian and all,


I believe that Magnum and HyperStack are targeting at different problems, 
though it certainly makes sense to integrate HyperStack as a bay type in 
Magnum, which we would love to explore later. I've setup a separate project for 
HyperStack: https://launchpad.net/hyperstack. My apology for the confusion.


I understand the concern of duplicating Nova and others. But imagine a vision 
that application can seamlessly migrate or scale out/in between LXC-based 
private CaaS and Hypervisor-based public CaaS, without the need to pre-build a 
bay. 


This ultimate portability & simplicity simply overweighs the rest!


HyperStack advocates the true multi-tenant, secure, public CaaS, which is 
really the first one and is built within OpenStack framework. I think 
HyperStack provides a seamless and probably the best path to upgrade to the 
container era.


For the team meeting, it is sometime very late for me (2am Beijing). I'll try 
to join more and look forward to speak with you and others in person.


Sorry again for the misunderstanding,
Peng


 
 
-- Original --
From:  "Adrian Otto";
Date:  Mon, Jul 27, 2015 12:43 PM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] Announcing HyperStack project

 
 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  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 ser

Re: [openstack-dev] Announcing HyperStack project

2015-07-26 Thread Adrian Otto

Peng,

http://lists.openstack.org/pipermail/openstack-dev/2015-July/069940.html

Regards,

Adrian

On Jul 26, 2015, at 7:40 PM, Peng Zhao mailto:p...@hyper.sh>>
wrote:

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Announcing HyperStack project

2015-07-26 Thread Peng Zhao

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

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Announcing HyperStack project

Re: [openstack-dev] Announcing HyperStack project

Re: [openstack-dev] Announcing HyperStack project

Re: [openstack-dev] Announcing HyperStack project

Re: [openstack-dev] Announcing HyperStack project

Re: [openstack-dev] Announcing HyperStack project

Re: [openstack-dev] Announcing HyperStack project

[openstack-dev] Announcing HyperStack project

8 matches

Site Navigation

Mail list logo

Footer information