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