Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)
Well, it is a myth that Docker is not linux container specific. It is born with cgroup/namespace, but the image is an app-centric way to package, nothing particular to linux container. For openstack, given the virtualization root, it is an easy win in places where requires strong isolation, multi-tenancy. And that creates new patterns to consume technologies. Peng - Hyper_ Secure Container Cloud On Wed, Apr 13, 2016 9:49 PM, Fox, Kevin M kevin@pnnl.gov wrote: It partially depends on if your following lightweight container methodology. Can nova api support unix sockets or bind mounts between containers in the same pod? Would it be reasonable to add that functionality? Its pretty different to novas usual use cases. Thanks, Kevin From: Peng Zhao Sent: Tuesday, April 12, 2016 11:33:21 PM To: OpenStack Development Mailing List (not for usage questions) Cc: foundat...@lists.openstack.org Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting) Agreed. IMO, OpenStack is an open framework to different technologies and use cases. Different architectures for different things make sense. Some may say that using nova to launch docker images with hypervisor is weird, but it can be seen as “Immutable IaaS”. - Hyper_ Secure Container Cloud On Wed, Apr 13, 2016 1:43 PM, Joshua Harlow harlo...@fastmail.com wrote: Sure, so that helps, except it still has the issue of bumping up against the mismatch of the API(s) of nova. This is why I'd rather have a template kind of format (as say the input API) that allows for (optionally) expressing such container specific capabilities/constraints. Then some project that can understand that template /format can if needed talk to a COE (or similar project) to translate that template 'segment' into a realized entity using the capabilities/constraints that the template specified. Overall it starts to feel like maybe it is time to change the upper and lower systems and shake things up a little ;) Peng Zhao wrote: > I'd take the idea further. Imagine a typical Heat template, what you > need to do is: > > - replace the VM id with Docker image id > - nothing else > - run the script with a normal heat engine > - the entire stack gets deployed in seconds > > Done! > > Well, that sounds like nova-docker. What about cinder and neutron? They > don't work well with Linux container! The answer is Hypernova > (https://github.com/hyperhq/hypernova) or Intel ClearContainer, seamless > integration with most OpenStack components. > > Summary: minimal changes to interface and upper systems, much smaller > image and much better developer workflow. > > Peng > > - > Hyper_ Secure Container Cloud > > > > On Wed, Apr 13, 2016 5:23 AM, Joshua Harlow harlo...@fastmail.com > wrote: > > __ Fox, Kevin M wrote: > I think part of the problem is containers > are mostly orthogonal to vms/bare metal. Containers are a package > for a single service. Multiple can run on a single vm/bare metal > host. Orchestration like Kubernetes comes in to turn a pool of > vm's/bare metal into a system that can easily run multiple > containers. > Is the orthogonal part a problem because we have made > it so or is it just how it really is? Brainstorming starts here: > Imagine a descriptor language like (which I stole from > https://review.openstack.org/#/c/210549 and modified): --- > components: - label: frontend count: 5 image: ubuntu_vanilla > requirements: high memory, low disk stateless: true - label: > database count: 3 image: ubuntu_vanilla requirements: high memory, > high disk stateless: false - label: memcache count: 3 image: > debian-squeeze requirements: high memory, no disk stateless: true - > label: zookeeper count: 3 image: debian-squeeze requirements: high > memory, medium disk stateless: false backend: VM networks: - label: > frontend_net flavor: “public network” associated_with: - frontend - > label: database_net flavor: high bandwidth associated_with: - > database - label: backend_net flavor: high bandwidth and low latency > associated_with: - zookeeper - memchache constraints: - ref: > container_only params: - frontend - ref: no_colocated params: - > database - frontend - ref: spread params: - database - ref: > no_colocated params: - database - frontend - ref: spread params: - > memcache - ref: spread params: - zookeeper - ref: isolated_network > params: - frontend_net - database_net - backend_net ... Now nothing > in the above is about container, or baremetal or vms, (although a > '
Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)
Agreed. IMO, OpenStack is an open framework to different technologies and use cases. Different architectures for different things make sense. Some may say that using nova to launch docker images with hypervisor is weird, but it can be seen as “Immutable IaaS”. - Hyper_ Secure Container Cloud On Wed, Apr 13, 2016 1:43 PM, Joshua Harlow harlo...@fastmail.com wrote: Sure, so that helps, except it still has the issue of bumping up against the mismatch of the API(s) of nova. This is why I'd rather have a template kind of format (as say the input API) that allows for (optionally) expressing such container specific capabilities/constraints. Then some project that can understand that template /format can if needed talk to a COE (or similar project) to translate that template 'segment' into a realized entity using the capabilities/constraints that the template specified. Overall it starts to feel like maybe it is time to change the upper and lower systems and shake things up a little ;) Peng Zhao wrote: > I'd take the idea further. Imagine a typical Heat template, what you > need to do is: > > - replace the VM id with Docker image id > - nothing else > - run the script with a normal heat engine > - the entire stack gets deployed in seconds > > Done! > > Well, that sounds like nova-docker. What about cinder and neutron? They > don't work well with Linux container! The answer is Hypernova > (https://github.com/hyperhq/hypernova) or Intel ClearContainer, seamless > integration with most OpenStack components. > > Summary: minimal changes to interface and upper systems, much smaller > image and much better developer workflow. > > Peng > > - > Hyper_ Secure Container Cloud > > > > On Wed, Apr 13, 2016 5:23 AM, Joshua Harlow harlo...@fastmail.com > wrote: > > __ Fox, Kevin M wrote: > I think part of the problem is containers > > are mostly orthogonal to vms/bare metal. Containers are a package > for a single service. Multiple can run on a single vm/bare metal > host. Orchestration like Kubernetes comes in to turn a pool of > vm's/bare metal into a system that can easily run multiple > containers. > Is the orthogonal part a problem because we have made > it so or is it just how it really is? Brainstorming starts here: > Imagine a descriptor language like (which I stole from > https://review.openstack.org/#/c/210549 and modified): --- > components: - label: frontend count: 5 image: ubuntu_vanilla > requirements: high memory, low disk stateless: true - label: > database count: 3 image: ubuntu_vanilla requirements: high memory, > high disk stateless: false - label: memcache count: 3 image: > debian-squeeze requirements: high memory, no disk stateless: true - > label: zookeeper count: 3 image: debian-squeeze requirements: high > memory, medium disk stateless: false backend: VM networks: - label: > frontend_net flavor: "public network" associated_with: - frontend - > label: database_net flavor: high bandwidth associated_with: - > database - label: backend_net flavor: high bandwidth and low latency > associated_with: - zookeeper - memchache constraints: - ref: > container_only params: - frontend - ref: no_colocated params: - > database - frontend - ref: spread params: - database - ref: > no_colocated params: - database - frontend - ref: spread params: - > memcache - ref: spread params: - zookeeper - ref: isolated_network > params: - frontend_net - database_net - backend_net ... Now nothing > in the above is about container, or baremetal or vms, (although a > 'advanced' constraint can be that a component must be on a > instead it's just about the constraints that a user has on there > deployment and the components associated with it. It can be left up > to some consuming project of that format to decide how to turn that > desired description into an actual description (aka a full expanding > of that format into an actual deployment plan), possibly say by > optimizing for density (packing as many things container) or > optimizing for security (by using VMs) or optimizing for performance > (by using bare-metal). > So, rather then concern itself with > supporting launching through a COE and through Nova, which are two > totally different code paths, OpenStack advanced services like Trove > could just use a Magnum COE and have a UI that asks which existing > Magnum COE to launch in, or alternately kick off the "Launch new > Magnum COE" workflow in horizon, then follow up with the Trove > launch workflow. Trove then would support being able to use > containers, users could potentially pack more containers onto their > vm's then just
Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)
I'd take the idea further. Imagine a typical Heat template, what you need to do is: - replace the VM id with Docker image id - nothing else - run the script with a normal heat engine - the entire stack gets deployed in seconds Done! Well, that sounds like nova-docker. What about cinder and neutron? They don't work well with Linux container! The answer is Hypernova (https://github.com/hyperhq/hypernova) or Intel ClearContainer, seamless integration with most OpenStack components. Summary: minimal changes to interface and upper systems, much smaller image and much better developer workflow. Peng - Hyper_ Secure Container Cloud On Wed, Apr 13, 2016 5:23 AM, Joshua Harlow harlo...@fastmail.com wrote: Fox, Kevin M wrote: > I think part of the problem is containers are mostly orthogonal to vms/bare metal. Containers are a package for a single service. Multiple can run on a single vm/bare metal host. Orchestration like Kubernetes comes in to turn a pool of vm's/bare metal into a system that can easily run multiple containers. > Is the orthogonal part a problem because we have made it so or is it just how it really is? Brainstorming starts here: Imagine a descriptor language like (which I stole from https://review.openstack.org/#/c/210549 and modified): --- components: - label: frontend count: 5 image: ubuntu_vanilla requirements: high memory, low disk stateless: true - label: database count: 3 image: ubuntu_vanilla requirements: high memory, high disk stateless: false - label: memcache count: 3 image: debian-squeeze requirements: high memory, no disk stateless: true - label: zookeeper count: 3 image: debian-squeeze requirements: high memory, medium disk stateless: false backend: VM networks: - label: frontend_net flavor: "public network instead it's just about the constraints that a user has on there deployment and the components associated with it. It can be left up to some consuming project of that format to decide how to turn that desired description into an actual description (aka a full expanding of that format into an actual deployment plan), possibly say by optimizing for density (packing as many things container) or optimizing for security (by using VMs) or optimizing for performance (by using bare-metal). > So, rather then concern itself with supporting launching through a COE and through Nova, which are two totally different code paths, OpenStack advanced services like Trove could just use a Magnum COE and have a UI that asks which existing Magnum COE to launch in, or alternately kick off the "Launch new Magnum COE" workflow in horizon, then follow up with the Trove launch workflow. Trove then would support being able to use containers, users could potentially pack more containers onto their vm's then just Trove, and it still would work with both Bare Metal and VM's the same way since Magnum can launch on either. I'm afraid supporting both containers and non container deployment with Trove will be a large effort with very little code sharing. It may be easiest to have a flag version where non container deployments are upgraded to containers then non container support is dropped. > Sure trove seems like it would be a consumer of whatever interprets that format, just like many other consumers could be (with the special case that trove creates such a format on-behalf of some other consumer, aka the trove user). > As for the app-catalog use case, the app-catalog project (http://apps.openstack.org) is working on some of that. > > Thanks, > Kevin > > From: Joshua Harlow [harlo...@fastmail.com] > Sent: Tuesday, April 12, 2016 12:16 PM OpenStack Development Mailing List (not for usage questions) > Cc: foundat...@lists.openstack.org > Subject: Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting) > > Flavio Percoco wrote: >> On 11/04/16 18:05 +, Amrith Kumar wrote: >>> Adrian, thx for your detailed mail. >>> >>> >>> >>> Yes, I was hopeful of a silver bullet and as we’ve discussed before (I >>> think it >>> was Vancouver), there’s likely no silver bullet in this area. After that >>> conversation, and some further experimentation, I found that even if >>> Trove had >>> access to a single Compute API, there were other significant >>> complications >>> further down the road, and I didn’t pursue the project further at the >>> time. >>> >> Adrian, Amrith, >> >> I've spent enough time researching on this area during the last month >> and my >> conclusion is pretty much the above. There's no silver bullet in this >> area and >> I'd argue there shouldn't be one. Containers, bare metal and VMs differ >> in such >> a way (feature-wise) that it'd not be good, as far as deploying >> databases goes, >> for there to be one compute API. Containers allow for a different >> deployment >> architecture than VMs and so does bare metal. > > Just some thoug
Re: [openstack-dev] [magnum]swarm + compose = k8s?
Hi, I wanted to give some thoughts to the thread. There are various perspective around “Hosted vs Self-managed COE”, But if you stand at the developer's position, it basically comes down to “Ops vs Flexibility”. For those who want more control of the stack, so as to customize in anyway they see fit, self-managed is a more appealing option. However, one may argue that the same job can be done with a heat template+some patchwork of cinder/neutron. And the heat template is more customizable than magnum, which probably introduces some requirements on the COE configuration. For people who don't want to manage the COE, hosted is a no-brainer. The question here is that which one is the core compute engine is the stack, nova or COE? Unless you are running a public, multi-tenant OpenStack deployment, it is highly likely that you are sticking with only one COE. Supposing k8s is what your team is dealing with everyday, then why you need nova sitting under k8s, whose job is just launching some VMs. After all, it is the COE that orchestrates cinder/neutron. One idea of this is to put COE at the same layer of nova. Instead of running atop nova, these two run side by side. So you got two compute engines: nova for IaaS workload, k8s for CaaS workload. If you go this way, hypernetes is probably what you are looking for. Another idea is “Dockerized (Immutable) IaaS”, e.g. replace Glance with Docker registry, and use nova to launch Docker images. But this is not done by nova-docker, simply because it is hard to integrate things like cinder/neutron with lxc. The idea is a nova-hyper driver . Since Hyper is hypervisor-based, it is much easier to make it work with others. SHAMELESS PROMOTION: if you are interested in this idea, we've submitted a proposal at the Austin summit: https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/8211 . Peng Disclaim: I maintainer Hyper. - Hyper - Make VM run like Container On Mon, Feb 15, 2016 at 9:53 AM, Hongbin Lu < hongbin...@huawei.com > wrote: My replies are inline. From: Kai Qiang Wu [mailto: wk...@cn.ibm.com ] Sent: February-14-16 7:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? HongBin, See my replies and questions in line. >> Thanks Best Wishes, -- -- Kai Qiang Wu ( 吴开强 Kennan ） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 -- -- Follow your heart. You are miracle! Hongbin Lu ---15/02/2016 01:26:09 am---Kai Qiang, A major benefit is to have Magnum manage the COEs for end-users. Currently, Magnum basica From: Hongbin Lu < hongbin...@huawei.com > To: “OpenStack Development Mailing List (not for usage questions)“ < openstack-dev@lists. openstack.org > Date: 15/02/2016 01:26 am Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Kai Qiang, A major benefit is to have Magnum manage the COEs for end-users. Currently, Magnum basically have its end-users manage the COEs by themselves after a successful deployment. This might work well for domain users, but it is a pain for non-domain users to manage their COEs. By moving master nodes out of users’ tenants, Magnum could offer users a COE management service. For example, Magnum could offer to monitor the etcd/swarm-manage clusters and recover them on failure. Again, the pattern of managing COEs for end-users is what Google container service and AWS container service offer. I guess it is fair to conclude that there are use cases out there? >> I am not sure when you talked about domain here, is it keystone domain or >> other case ? What's the non-domain users case to manage the COEs? Reply: I mean domain experts, someone who are experts of kubernetes/swarm/mesos. If we decide to offer a COE management service, we could discuss further on how to consolidate the IaaS resources for improving utilization. Solutions could be (i) introducing a centralized control services for all tenants/clusters, or (ii) keeping the control services separated but isolating them by containers (instead of VMs). A typical use case is what Kris mentioned below. >> for (i) it is more complicated than (ii), and I did not see much benefits >> gain for utilization case here for (i), instead it could introduce much burden for upgrade case and service interference for all tenants/clusters Reply: Definitely we could discuss it further. I don’t have preference in mind right now. Best regards, Hongbin From: Kai Qiang Wu [ mailto:wk...@cn.ibm.com ] Sent: February-13-16
Re: [openstack-dev] [magnum] Autoscaling both clusters and containers
Ryan, That's where Hyper could help. This blog talks about wasted capacity issue and the solution: http://thenewstack.io/hypernetes-brings-multi-tenancy-microservices/ Best Peng - Hyper - Make VM run like Container On Wed, Nov 18, 2015 at 6:03 AM, Ryan Rossiter < rlros...@linux.vnet.ibm.com > wrote: Hi all, I was having a discussion with a teammate with respect to container scaling. He likes the aspect of nova-docker that allows you to scale (essentially) infinitely almost instantly, assuming you are using a large pool of compute hosts. In the case of Magnum, if I'm a container user, I don't want to be paying for a ton of vms that just sit idle, but I also want to have enough vms to handle my scale when I infrequently need it. But above all, when I need scale, I don't want to suddenly have to go boot vms and wait for them to start up when I really need it. I saw [1] which discusses container scaling, but I'm thinking we can take this one step further. If I don't want to pay for a lot of vms when I'm not using them, could I set up an autoscale policy that allows my cluster to expand when my container concentration gets too high on my existing cluster? It's kind of a case of nested autoscaling. The containers are scaled based on request demand, and the cluster vms are scaled based on container count. I'm unsure of the details of Senlin, but at least looking at Heat autoscaling [2], this would not be very hard to add to the Magnum templates, and we would forward those on through the bay API. (I figure we would do this through the bay, not baymodel, because I can see similar clusters that would want to be scaled differently). Let me know if I'm totally crazy or if this is a good idea (or if you guys have already talked about this before). I would be interested in your feedback. [1] http://lists.openstack.org/pip ermail/openstack-dev/2015-Nove mber/078628.html [2] https://wiki.openstack.org/wik i/Heat/AutoScaling#AutoScaling _API -- Thanks, Ryan Rossiter (rlrossit) __ __ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.op enstack.org?subject:unsubscrib e http://lists.openstack.org/cgi -bin/mailman/listinfo/openstac k-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
Re: [openstack-dev] [magnum]swarm + compose = k8s?
Echo with Monty: > I believe that the real win is if Magnum's control plan can integrate the network and storage fabrics > that exist in an OpenStack with kube/mesos/swarm. We are working on the Cinder (ceph), Neutron, Keystone integration in HyperStack [1] and love to contribute. Another TODO is the multi-tenancy support in k8s/swarm/mesos. A global scheduler/orchestrator for all tenants yields higher utilization rate than separate schedulers for each. [1] https://launchpad.net/hyperstack - Hyper - Make VM run like Container On Wed, Sep 30, 2015 at 12:00 PM, Monty Taylor < mord...@inaugust.com > wrote: *waving hands wildly at details* ... I believe that the real win is if Magnum's control plan can integrate the network and storage fabrics that exist in an OpenStack with kube/mesos/swarm. Just deploying is VERY meh. I do not care - it's not interesting ... an ansible playbook can do that in 5 minutes. OTOH - deploying some kube into a cloud in such a way that it shares a tenant network with some VMs that are there - that's good stuff and I think actually provides significant value. On 09/29/2015 10:57 PM, Jay Lau wrote: +1 to Egor, I think that the final goal of Magnum is container as a service but not coe deployment as a service. ;-) Especially we are also working on Magnum UI, the Magnum UI should export some interfaces to enable end user can create container applications but not only coe deployment. I hope that the Magnum can be treated as another “Nova” which is focusing on container service. I know it is difficult to unify all of the concepts in different coe (k8s has pod, service, rc, swarm only has container, nova only has VM, PM with different hypervisors), but this deserve some deep dive and thinking to see how can move forward. On Wed, Sep 30, 2015 at 1:11 AM, Egor Guz < e...@walmartlabs.com > wrote: definitely ;), but the are some thoughts to Tom’s email. I agree that we shouldn't reinvent apis, but I don’t think Magnum should only focus at deployment (I feel we will become another Puppet/Chef/Ansible module if we do it ):) I belive our goal should be seamlessly integrate Kub/Mesos/Swarm to OpenStack ecosystem (Neutron/Cinder/Barbican/etc) even if we need to step in to Kub/Mesos/Swarm communities for that. — Egor From: Adrian Otto < adrian.o...@rackspace.com >> Reply-To: “OpenStack Development Mailing List (not for usage questions)“ < openstack-dev@lists.openstack .org >> Date: Tuesday, September 29, 2015 at 08:44 To: “OpenStack Development Mailing List (not for usage questions)“ < openstack-dev@lists.openstack .org >> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? This is definitely a topic we should cover in Tokyo. On Sep 29, 2015, at 8:28 AM, Daneyon Hansen (danehans) < daneh...@cisco.com >> wrote: +1 From: Tom Cammann < tom.camm...@hpe.com >> Reply-To: “ openstack-dev@lists.openstack .org >” < openstack-dev@lists.openstack .org >> Date: Tuesday, September 29, 2015 at 2:22 AM To: “ openstack-dev@lists.openstack .org >” < openstack-dev@lists.openstack .org >> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? This has been my thinking in the last couple of months to completely deprecate the COE specific APIs such as pod/service/rc and container. As we now support Mesos, Kubernetes and Docker Swarm its going to be very difficult and probably a wasted effort trying to consolidate their separate APIs under a single Magnum API. I'm starting to see Magnum as COEDaaS - Container Orchestration Engine Deployment as a Service. On 29/09/15 06:30, Ton Ngo wrote: Would it make sense to ask the opposite of Wanghua's question: should pod/service/rc be deprecated if the user can easily get to the k8s api? Even if we want to orchestrate these in a Heat template, the corresponding heat resources can just interface with k8s instead of Magnum. Ton Ngo, Egor Guz ---09/28/2015 10:20:02 PM---Also I belive docker compose is just command line tool which doesn’t have any api or scheduling feat From: Egor Guz < e...@walmartlabs.com > > To: “ openstack-dev@lists.openstack .org “> < openstack-dev@lists.openstack .org >> Date: 09/28/2015 10:20 PM Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? __ __ Also I belive docker compose is just command line tool which doesn’t have any api or scheduling features. But during last Docker Conf hackathon PayPal folks implemented docker compose executor for Mesos ( https://github.com/mohitsoni/ compose-executor ) which can give you pod like experience. — Egor From: Adrian Otto < adrian.o...@rackspace.com >>> Reply-To: “OpenStack Development Mailing List (not for usage questions)“ < openstack-dev@lists.openstack .org >>> Date: Monday, September 28, 2015 at 22:03 To: “OpenStack Development Mailing List (not for usage questions)“ < openstack-dev@lists.openstack .org >>> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? Wanghua, I do
Re: [openstack-dev] Announcing HyperStack project
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
[openstack-dev] Announcing HyperStack project
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper
Adrian, Let's say someone creates a Hyper bay. The bay will be sth. like BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. What nova does in this scenario is to provision the Hyper+BM hosts. Things like LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by HyperStack, not nova. Therefore, a second core besides nova is inevitable. Speaking of duplication, HyperStack leverages Cinder and Neutron, which protects ROI. Looking at the overall puzzle, one of the biggest missing pieces is a solution of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid case, but more for someone who wants to provides CaaS within their IaaS (nova) platform. We plan to present a working beta of HyperStack on Tokyo summit. The next step is to integrate HyperStack with bay for more advanced deployment. Best, Peng -- Original -- From: "Adrian Otto"; Date: Sun, Jul 19, 2015 11:11 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, You are not the first to think this way, and it's one of the reasons we did not integrate Containers with OpenStack in a meaningful way a full year earlier. Please pay attention closely. 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will get killed. Operators matter. 2) Cloud Operators need a consistent way to bill for the IaaS services the provide. Nova emits all of the RPC messages needed to do this. Having a second nova that does this slightly differently is a really annoying problem that will make Operators hate the software. It's better to use nova, have things work consistently, and plug in virt drivers to it. 3) Creation of a host is only part of the problem. That's the easy part. Nova also does a bunch of other things too. For example, say you want to live migrate a guest from one host to another. There is already functionality in Nova for doing that. 4) Resources need to be capacity managed. We call this scheduling. Nova has a pluggable scheduler to help with the placement of guests on hosts. Magnum will not. 5) Hosts in a cloud need to integrate with a number of other services, such as an image service, messaging, networking, storage, etc. If you only think in terms of host creation, and do something without nova, then you need to re-integrate with all of these things. Now, I probably left out examples of lots of other things that Nova does. What I have mentioned us enough to make my point that there are a lot of things that Magnum is intentionally NOT doing that we expect to get from Nova, and I will block all code that gratuitously duplicates functionality that I believe belongs in Nova. I promised our community I would not duplicate existing functionality without a very good reason, and I will keep that promise. Let's find a good way to fit Hyper with OpenStack in a way that best leverages what exists today, and is least likely to be rejected. Please note that the proposal needs to be changed from where it is today to achieve this fit. My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. Thanks, Adrian ---- Original message From: Peng Zhao Date: 07/19/2015 5:36 AM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Thanks Jay. Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I just think bay isn't a must in this case, and we don't need nova to provision BM hosts, which makes things more complicated imo. Peng -- Original -- From: "Jay Lau"; Date: Sun, Jul 19, 2015 10:36 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Hong Bin, I have some online discussion with Peng, seems hyper is now integrating with Kubernetes and also have plan integrate with mesos for scheduling. Once mesos integration finished, we can treat mesos+hyper as another kind of bay. Thanks 2015-07-19 4:15 GMT+08:00 Hongbin Lu : Peng, Several questions Here. You mentioned that HyperStack is a single big “bay”. Then, who is doing the multi-host scheduling, Hyper or something else? Were you suggesting to integrate Hyper with Magnum directly? Or you were suggesting to integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)? Best re
Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper
Adrian, Let's say someone creates a Hyper bay. The bay will be sth. like BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. What nova does in this scenario is to provision the Hyper+BM hosts. Things like LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by HyperStack, not nova. Therefore, a second core besides nova is inevitable. Speaking of duplication, HyperStack leverages Cinder and Neutron, which protects ROI. Looking at the overall puzzle, one of the biggest missing pieces is a solution of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid case, but more for someone who wants to provides CaaS within their IaaS (nova) platform. We plan to present a working beta of HyperStack on Tokyo summit. The next step is to integrate HyperStack with bay for more advanced deployment. Best, Peng -- Original -- From: "Adrian Otto"; Date: Sun, Jul 19, 2015 11:11 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, You are not the first to think this way, and it's one of the reasons we did not integrate Containers with OpenStack in a meaningful way a full year earlier. Please pay attention closely. 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will get killed. Operators matter. 2) Cloud Operators need a consistent way to bill for the IaaS services the provide. Nova emits all of the RPC messages needed to do this. Having a second nova that does this slightly differently is a really annoying problem that will make Operators hate the software. It's better to use nova, have things work consistently, and plug in virt drivers to it. 3) Creation of a host is only part of the problem. That's the easy part. Nova also does a bunch of other things too. For example, say you want to live migrate a guest from one host to another. There is already functionality in Nova for doing that. 4) Resources need to be capacity managed. We call this scheduling. Nova has a pluggable scheduler to help with the placement of guests on hosts. Magnum will not. 5) Hosts in a cloud need to integrate with a number of other services, such as an image service, messaging, networking, storage, etc. If you only think in terms of host creation, and do something without nova, then you need to re-integrate with all of these things. Now, I probably left out examples of lots of other things that Nova does. What I have mentioned us enough to make my point that there are a lot of things that Magnum is intentionally NOT doing that we expect to get from Nova, and I will block all code that gratuitously duplicates functionality that I believe belongs in Nova. I promised our community I would not duplicate existing functionality without a very good reason, and I will keep that promise. Let's find a good way to fit Hyper with OpenStack in a way that best leverages what exists today, and is least likely to be rejected. Please note that the proposal needs to be changed from where it is today to achieve this fit. My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. Thanks, Adrian ---- Original message From: Peng Zhao Date: 07/19/2015 5:36 AM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Thanks Jay. Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I just think bay isn't a must in this case, and we don't need nova to provision BM hosts, which makes things more complicated imo. Peng -- Original -- From: "Jay Lau"; Date: Sun, Jul 19, 2015 10:36 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Hong Bin, I have some online discussion with Peng, seems hyper is now integrating with Kubernetes and also have plan integrate with mesos for scheduling. Once mesos integration finished, we can treat mesos+hyper as another kind of bay. Thanks 2015-07-19 4:15 GMT+08:00 Hongbin Lu : Peng, Several questions Here. You mentioned that HyperStack is a single big “bay”. Then, who is doing the multi-host scheduling, Hyper or something else? Were you suggesting to integrate Hyper with Magnum directly? Or you were suggesting to integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)? Best re
Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper
Adrian, Let's say someone creates a Hyper bay. The bay will be sth. like BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. What nova does in this scenario is to provision the Hyper+BM hosts. Things like LiveMigration, Multi-tenancy, Billing, etc., are handled by HyperStack, not nova. Therefore, a second core besides nova is inevitable. Looking at the overall puzzle, one of the biggest missing pieces is a solution of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid case, but more for someone who wants to provides CaaS within their IaaS (nova) platform. We plan to present a working beta of HyperStack on Tokyo summit. The next step is to integrate HyperStack with bay for more advanced deployment. Best, Peng -- Original -- From: "Adrian Otto"; Date: Sun, Jul 19, 2015 11:11 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, You are not the first to think this way, and it's one of the reasons we did not integrate Containers with OpenStack in a meaningful way a full year earlier. Please pay attention closely. 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will get killed. Operators matter. 2) Cloud Operators need a consistent way to bill for the IaaS services the provide. Nova emits all of the RPC messages needed to do this. Having a second nova that does this slightly differently is a really annoying problem that will make Operators hate the software. It's better to use nova, have things work consistently, and plug in virt drivers to it. 3) Creation of a host is only part of the problem. That's the easy part. Nova also does a bunch of other things too. For example, say you want to live migrate a guest from one host to another. There is already functionality in Nova for doing that. 4) Resources need to be capacity managed. We call this scheduling. Nova has a pluggable scheduler to help with the placement of guests on hosts. Magnum will not. 5) Hosts in a cloud need to integrate with a number of other services, such as an image service, messaging, networking, storage, etc. If you only think in terms of host creation, and do something without nova, then you need to re-integrate with all of these things. Now, I probably left out examples of lots of other things that Nova does. What I have mentioned us enough to make my point that there are a lot of things that Magnum is intentionally NOT doing that we expect to get from Nova, and I will block all code that gratuitously duplicates functionality that I believe belongs in Nova. I promised our community I would not duplicate existing functionality without a very good reason, and I will keep that promise. Let's find a good way to fit Hyper with OpenStack in a way that best leverages what exists today, and is least likely to be rejected. Please note that the proposal needs to be changed from where it is today to achieve this fit. My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. Thanks, Adrian ---- Original message From: Peng Zhao Date: 07/19/2015 5:36 AM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Thanks Jay. Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I just think bay isn't a must in this case, and we don't need nova to provision BM hosts, which makes things more complicated imo. Peng -- Original -- From: "Jay Lau"; Date: Sun, Jul 19, 2015 10:36 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Hong Bin, I have some online discussion with Peng, seems hyper is now integrating with Kubernetes and also have plan integrate with mesos for scheduling. Once mesos integration finished, we can treat mesos+hyper as another kind of bay. Thanks 2015-07-19 4:15 GMT+08:00 Hongbin Lu : Peng, Several questions Here. You mentioned that HyperStack is a single big “bay”. Then, who is doing the multi-host scheduling, Hyper or something else? Were you suggesting to integrate Hyper with Magnum directly? Or you were suggesting to integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)? Best regards, Hongbin From: Peng Zhao [mailto:p...@hyper.sh] Sent: July-17-15 12:34 PM To: Op
Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwithHyper
I had some problem with my email server today, so you may see several identical messages from me in the ML. Please ignore and sorry about that. Peng -- Original -- From: "Peng Zhao"; Date: Mon, Jul 20, 2015 11:41 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwithHyper Hi, Jay, Adrian and Wu, I have some problems with my mail server to reply Adrian's message. So let me write here. Let's say someone creates a Hyper bay. The bay will be sth. like BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. What nova does in this scenario is to provision the Hyper+BM hosts. Things like LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by HyperStack, not nova. Therefore, a second core besides nova is inevitable. Speaking of duplication, HyperStack leverages Cinder and Neutron, which protects ROI. Looking at the overall puzzle, one of the biggest missing pieces is a solution of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid case, but more for someone who wants to provides CaaS within their IaaS (nova) platform. We plan to present a working beta of HyperStack on Tokyo summit. The next step is to integrate HyperStack with bay for more advanced deployment. Best, Peng -- Original -- From: "Jay Lau"; Date: Mon, Jul 20, 2015 11:18 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwithHyper The nova guys propose move Hyper to Magnum but not Nova as Hyper cannot fit into nova virt driver well. As Hyper is now integrating with Kubernetes, I think that the integration point may be creating a kubernetes hyper bay with ironic driver. Thanks 2015-07-20 10:00 GMT+08:00 Kai Qiang Wu : Hi Peng, As @Adrian pointed it out: My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. I remembered you or other guys in your company proposed one bp about nova virt driver for Hyper. What's the status of the bp now? Is it accepted by nova projects or cancelled ? Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! Adrian Otto ---07/19/2015 11:18:02 PM---Peng, You are not the first to think this way, and it's one of the reasons we did not integrate Cont From: Adrian Otto To:"OpenStack Development Mailing List (not for usage questions)" Date: 07/19/2015 11:18 PM Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Peng, You are not the first to think this way, and it's one of the reasons we did not integrate Containers with OpenStack in a meaningful way a full year earlier. Please pay attention closely. 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will get killed. Operators matter. 2) Cloud Operators need a consistent way to bill for the IaaS services the provide. Nova emits all of the RPC messages needed to do this. Having a second nova that does this slightly differently is a really annoying problem that will make Operators hate the software. It's better to use nova, have things work consistently, and plug in virt drivers to it. 3) Creation of a host is only part of the problem. That's the easy part. Nova also does a bunch of other things too. For example, say you want to live migrate a guest from one host to another. There is already functionality in Nova for doing that. 4) Resources need to be capacity managed. We call this scheduling. Nova has a pluggable scheduler to help with the placement of guests on hosts. Magnum will not. 5) Hosts in a cloud need to integrate with a number of other services, such as an image service, messaging, networking, storage, etc. If you only think in terms of host creation, and do something without nova, then you need to re-integrate with all of these things. Now, I probably left out examples of lots of other things that Nova does. What I have mentioned us enough to make my point that there are a lot of things that Magnum is intentionally NOT doing that we expect to get from Nova, and I
Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwithHyper
s today to achieve this fit. My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. Thanks, Adrian Original message From: Peng Zhao Date: 07/19/2015 5:36 AM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Thanks Jay. Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I just think bay isn't a must in this case, and we don't need nova to provision BM hosts, which makes things more complicated imo. Peng -- Original -- From: "Jay Lau"; Date: Sun, Jul 19, 2015 10:36 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Hong Bin, I have some online discussion with Peng, seems hyper is now integrating with Kubernetes and also have plan integrate with mesos for scheduling. Once mesos integration finished, we can treat mesos+hyper as another kind of bay. Thanks 2015-07-19 4:15 GMT+08:00 Hongbin Lu : Peng, Several questions Here. You mentioned that HyperStack is a single big “bay”. Then, who is doing the multi-host scheduling, Hyper or something else? Were you suggesting to integrate Hyper with Magnum directly? Or you were suggesting to integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)? Best regards, Hongbin From: Peng Zhao [mailto:p...@hyper.sh] Sent: July-17-15 12:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal with Hyper Hi, Adrian, Jay and all, There could be a much longer version of this, but let me try to explain in a minimalist way. Bay currently has two modes: VM-based, BM-based. In both cases, Bay helps to isolate different tenants' containers. In other words, bay is single-tenancy. For BM-based bay, the single tenancy is a worthy tradeoff, given the performance merits of LXC vs VM. However, for a VM-based bay, there is no performance gain, but single tenancy seems a must, due to the lack of isolation in container. Hyper, as a hypervisor-based substitute for container, brings the much-needed isolation, and therefore enables multi-tenancy. In HyperStack, we don't really need Ironic to provision multiple Hyper bays. On the other hand, the entire HyperStack cluster is a single big "bay". Pretty similar to how Nova works. Also, HyperStack is able to leverage Cinder, Neutron for SDS/SDN functionality. So when someone submits a Docker Compose app, HyperStack would launch HyperVMs and call Cinder/Neutron to setup the volumes and network. The architecture is quite simple. Here are a blog I'd like to recommend: https://hyper.sh/blog/post/2015/06/29/docker-hyper-and-the-end-of-guest-os.html Let me know your questions. Thanks, Peng -- Original -- From: "Adrian Otto"; Date: Thu, Jul 16, 2015 11:02 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwith Hyper Jay, Hyper is a substitute for a Docker host, so I expect it could work equally well for all of the current bay types. Hyper’s idea of a “pod” and a Kubernetes “pod” are similar, but different. I’m not yet convinced that integrating Hyper host creation direct with Magnum (and completely bypassing nova) is a good idea. It probably makes more sense to implement use nova with the ironic dirt driver to provision Hyper hosts so we can use those as substitutes for Bay nodes in our various Bay types. This would fit in the place were we use Fedora Atomic today. We could still rely on nova to do all of the machine instance management and accounting like we do today, but produce bays that use Hyper instead of a Docker host. Everywhere we currently offer CoreOS as an option we could also offer Hyper as an alternative, with some caveats. There may be some caveats/drawbacks to consider before committing to a Hyper integration. I’ll be asking those of Peng also on this thread, so keep an eye out. Thanks, Adrian On Jul 16, 2015, at 3:23 AM, Jay Lau wrote: Thanks Peng, then I can see two integration points for Magnum and Hyper: 1) Once Hyper and k8s integration finished, we can deploy k8s in two mode: docker and hyper mode, the end user can select which mode they want to use. For such case, we do not need to create a new bay but may need some enhancement for current k8s bay 2) After mesos and hyper integration,
Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper
Adrian, Let's say someone creates a Hyper bay. The bay will be sth. like BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. What nova does in this scenario is to provision the Hyper+BM hosts. Things like LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by HyperStack, not nova. Therefore, a second core besides nova is inevitable. Speaking of duplication, HyperStack leverages Cinder and Neutron, which protects ROI. Looking at the overall puzzle, one of the biggest missing pieces is a solution of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid case, but more for someone who wants to provides CaaS within their IaaS (nova) platform. We plan to present a working beta of HyperStack on Tokyo summit. The next step is to integrate HyperStack with bay for more advanced deployment. Best, Peng -- Original -- From: "Adrian Otto"; Date: Sun, Jul 19, 2015 11:11 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, You are not the first to think this way, and it's one of the reasons we did not integrate Containers with OpenStack in a meaningful way a full year earlier. Please pay attention closely. 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will get killed. Operators matter. 2) Cloud Operators need a consistent way to bill for the IaaS services the provide. Nova emits all of the RPC messages needed to do this. Having a second nova that does this slightly differently is a really annoying problem that will make Operators hate the software. It's better to use nova, have things work consistently, and plug in virt drivers to it. 3) Creation of a host is only part of the problem. That's the easy part. Nova also does a bunch of other things too. For example, say you want to live migrate a guest from one host to another. There is already functionality in Nova for doing that. 4) Resources need to be capacity managed. We call this scheduling. Nova has a pluggable scheduler to help with the placement of guests on hosts. Magnum will not. 5) Hosts in a cloud need to integrate with a number of other services, such as an image service, messaging, networking, storage, etc. If you only think in terms of host creation, and do something without nova, then you need to re-integrate with all of these things. Now, I probably left out examples of lots of other things that Nova does. What I have mentioned us enough to make my point that there are a lot of things that Magnum is intentionally NOT doing that we expect to get from Nova, and I will block all code that gratuitously duplicates functionality that I believe belongs in Nova. I promised our community I would not duplicate existing functionality without a very good reason, and I will keep that promise. Let's find a good way to fit Hyper with OpenStack in a way that best leverages what exists today, and is least likely to be rejected. Please note that the proposal needs to be changed from where it is today to achieve this fit. My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. Thanks, Adrian ---- Original message From: Peng Zhao Date: 07/19/2015 5:36 AM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Thanks Jay. Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I just think bay isn't a must in this case, and we don't need nova to provision BM hosts, which makes things more complicated imo. Peng -- Original -- From: "Jay Lau"; Date: Sun, Jul 19, 2015 10:36 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Hong Bin, I have some online discussion with Peng, seems hyper is now integrating with Kubernetes and also have plan integrate with mesos for scheduling. Once mesos integration finished, we can treat mesos+hyper as another kind of bay. Thanks 2015-07-19 4:15 GMT+08:00 Hongbin Lu : Peng, Several questions Here. You mentioned that HyperStack is a single big “bay”. Then, who is doing the multi-host scheduling, Hyper or something else? Were you suggesting to integrate Hyper with Magnum directly? Or you were suggesting to integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)? Best regard
Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper
Adrian, Let's say someone creates a Hyper bay. The bay will be sth. like BM+Hyper+Cinder+Neutron+k8s/mesos/swarm. This is exactly a mini HyperStack. What nova does in this scenario is to provision the Hyper+BM hosts. Things like LiveMigration, Multi-tenancy, Billing, VPC, Volume, etc., are handled by HyperStack, not nova. Therefore, a second core besides nova is inevitable. Speaking of duplication, HyperStack leverages Cinder and Neutron, which protects ROI. Looking at the overall puzzle, one of the biggest missing pieces is a solution of the native CaaS. And HyperStack wants to fill that gap. Hyper bay is a valid case, but more for someone who wants to provides CaaS within their IaaS (nova) platform. We plan to present a working beta of HyperStack on Tokyo summit. The next step is to integrate HyperStack with bay for more advanced deployment. Best, Peng -- Original -- From: "Adrian Otto"; Date: Sun, Jul 19, 2015 11:11 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, You are not the first to think this way, and it's one of the reasons we did not integrate Containers with OpenStack in a meaningful way a full year earlier. Please pay attention closely. 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will get killed. Operators matter. 2) Cloud Operators need a consistent way to bill for the IaaS services the provide. Nova emits all of the RPC messages needed to do this. Having a second nova that does this slightly differently is a really annoying problem that will make Operators hate the software. It's better to use nova, have things work consistently, and plug in virt drivers to it. 3) Creation of a host is only part of the problem. That's the easy part. Nova also does a bunch of other things too. For example, say you want to live migrate a guest from one host to another. There is already functionality in Nova for doing that. 4) Resources need to be capacity managed. We call this scheduling. Nova has a pluggable scheduler to help with the placement of guests on hosts. Magnum will not. 5) Hosts in a cloud need to integrate with a number of other services, such as an image service, messaging, networking, storage, etc. If you only think in terms of host creation, and do something without nova, then you need to re-integrate with all of these things. Now, I probably left out examples of lots of other things that Nova does. What I have mentioned us enough to make my point that there are a lot of things that Magnum is intentionally NOT doing that we expect to get from Nova, and I will block all code that gratuitously duplicates functionality that I believe belongs in Nova. I promised our community I would not duplicate existing functionality without a very good reason, and I will keep that promise. Let's find a good way to fit Hyper with OpenStack in a way that best leverages what exists today, and is least likely to be rejected. Please note that the proposal needs to be changed from where it is today to achieve this fit. My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. Thanks, Adrian ---- Original message From: Peng Zhao Date: 07/19/2015 5:36 AM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Thanks Jay. Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I just think bay isn't a must in this case, and we don't need nova to provision BM hosts, which makes things more complicated imo. Peng -- Original -- From: "Jay Lau"; Date: Sun, Jul 19, 2015 10:36 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Hong Bin, I have some online discussion with Peng, seems hyper is now integrating with Kubernetes and also have plan integrate with mesos for scheduling. Once mesos integration finished, we can treat mesos+hyper as another kind of bay. Thanks 2015-07-19 4:15 GMT+08:00 Hongbin Lu : Peng, Several questions Here. You mentioned that HyperStack is a single big “bay”. Then, who is doing the multi-host scheduling, Hyper or something else? Were you suggesting to integrate Hyper with Magnum directly? Or you were suggesting to integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)? Best regard
Re: [openstack-dev] [magnum][bp] Power Magnum to runon metal withHyper
It looks like that Nova team has no plan to accept either nova-docker driver or nova-hyper. The focus of Nova is "Server-like" instance, not App-centric container. That is fine. It's the best to let Nova be Nova, and build sth. else for container. After all, different use cases, different needs, different solutions. Peng -- Original -- From: "Kai Qiang Wu"; Date: Mon, Jul 20, 2015 10:00 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to runonmetal withHyper Hi Peng, As @Adrian pointed it out: My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. I remembered you or other guys in your company proposed one bp about nova virt driver for Hyper. What's the status of the bp now? Is it accepted by nova projects or cancelled ? Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! Adrian Otto ---07/19/2015 11:18:02 PM---Peng, You are not the first to think this way, and it's one of the reasons we did not integrate Cont From: Adrian Otto To:"OpenStack Development Mailing List (not for usage questions)" Date: 07/19/2015 11:18 PM Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Peng, You are not the first to think this way, and it's one of the reasons we did not integrate Containers with OpenStack in a meaningful way a full year earlier. Please pay attention closely. 1) OpenStack's key influences care about two personas: 1.1) Cloud Operators 1.2) Cloud Consumers. If you only think in terms of 1.2, then your idea will get killed. Operators matter. 2) Cloud Operators need a consistent way to bill for the IaaS services the provide. Nova emits all of the RPC messages needed to do this. Having a second nova that does this slightly differently is a really annoying problem that will make Operators hate the software. It's better to use nova, have things work consistently, and plug in virt drivers to it. 3) Creation of a host is only part of the problem. That's the easy part. Nova also does a bunch of other things too. For example, say you want to live migrate a guest from one host to another. There is already functionality in Nova for doing that. 4) Resources need to be capacity managed. We call this scheduling. Nova has a pluggable scheduler to help with the placement of guests on hosts. Magnum will not. 5) Hosts in a cloud need to integrate with a number of other services, such as an image service, messaging, networking, storage, etc. If you only think in terms of host creation, and do something without nova, then you need to re-integrate with all of these things. Now, I probably left out examples of lots of other things that Nova does. What I have mentioned us enough to make my point that there are a lot of things that Magnum is intentionally NOT doing that we expect to get from Nova, and I will block all code that gratuitously duplicates functionality that I believe belongs in Nova. I promised our community I would not duplicate existing functionality without a very good reason, and I will keep that promise. Let's find a good way to fit Hyper with OpenStack in a way that best leverages what exists today, and is least likely to be rejected. Please note that the proposal needs to be changed from where it is today to achieve this fit. My fist suggestion is to find a way to make a nova virt driver for Hyper, which could allow it to be used with all of our current Bay types in Magnum. Thanks, Adrian Original message From: Peng Zhao Date: 07/19/2015 5:36 AM (GMT-08:00) To: "OpenStack Development Mailing List (not for usage questions)" Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Thanks Jay. Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I just think bay isn't a must in this case, and we don't need nova to provision BM hosts, which makes things more complicated imo. Peng -- Original -- From: "Jay Lau"; Date: Sun, Jul 19, 2015 10:36 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][
Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper
Hi Jay, My idea is that if someone wants an IaaS solution, go Nova+Cinder+Neutron. For private CaaS solution, K8S/Mesos+Cinder+Neutron(libnetwork?)+Docker, for public CaaS, go K8S/Mesos+Cinder+Neutron+Hyper. By doing this, we could clearly deliver the message to the community and market. What you suggested is more of a hybrid cluster. It is of course a valid case, though I think it should be a more advanced stage. Currently, most CaaS are deployed on some IaaS, and viewed by many as an extension of IaaS. With HyperStack, we could redefine the cloud by introducing a native, secure, multi-tenant CaaS. And all of these can be done in the OpenStack framework. Best, Peng -- Original -- From: "Jay Lau"; Date: Sun, Jul 19, 2015 10:32 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Hi Peng, Please check some of my understandings in line. Thanks 2015-07-18 0:33 GMT+08:00 Peng Zhao : Hi, Adrian, Jay and all, There could be a much longer version of this, but let me try to explain in a minimalist way. Bay currently has two modes: VM-based, BM-based. In both cases, Bay helps to isolate different tenants' containers. In other words, bay is single-tenancy. For BM-based bay, the single tenancy is a worthy tradeoff, given the performance merits of LXC vs VM. However, for a VM-based bay, there is no performance gain, but single tenancy seems a must, due to the lack of isolation in container. Hyper, as a hypervisor-based substitute for container, brings the much-needed isolation, and therefore enables multi-tenancy. In HyperStack, we don't really need Ironic to provision multiple Hyper bays. On the other hand, the entire HyperStack cluster is a single big "bay". Pretty similar to how Nova works. IMHO, only creating one big bay might not fit into Magnum user scenario well, what you mentioned that put the entire HyperStack as a single big bay is more like a public cloud case. But for some private cloud cases, there are different users and tenants, and different tenants might want to set up their own HyperStack bay on their own resources. Also, HyperStack is able to leverage Cinder, Neutron for SDS/SDN functionality. So when someone submits a Docker Compose app, HyperStack would launch HyperVMs and call Cinder/Neutron to setup the volumes and network. The architecture is quite simple. This is cool! Here are a blog I'd like to recommend: https://hyper.sh/blog/post/2015/06/29/docker-hyper-and-the-end-of-guest-os.html Let me know your questions. Thanks, Peng -- Original -- From: "Adrian Otto"; Date: Thu, Jul 16, 2015 11:02 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwith Hyper Jay, Hyper is a substitute for a Docker host, so I expect it could work equally well for all of the current bay types. Hyper’s idea of a “pod” and a Kubernetes “pod” are similar, but different. I’m not yet convinced that integrating Hyper host creation direct with Magnum (and completely bypassing nova) is a good idea. It probably makes more sense to implement use nova with the ironic dirt driver to provision Hyper hosts so we can use those as substitutes for Bay nodes in our various Bay types. This would fit in the place were we use Fedora Atomic today. We could still rely on nova to do all of the machine instance management and accounting like we do today, but produce bays that use Hyper instead of a Docker host. Everywhere we currently offer CoreOS as an option we could also offer Hyper as an alternative, with some caveats. There may be some caveats/drawbacks to consider before committing to a Hyper integration. I’ll be asking those of Peng also on this thread, so keep an eye out. Thanks, Adrian On Jul 16, 2015, at 3:23 AM, Jay Lau wrote: Thanks Peng, then I can see two integration points for Magnum and Hyper: 1) Once Hyper and k8s integration finished, we can deploy k8s in two mode: docker and hyper mode, the end user can select which mode they want to use. For such case, we do not need to create a new bay but may need some enhancement for current k8s bay 2) After mesos and hyper integration, we can treat mesos and hyper as a new bay to magnum. Just like what we are doing now for mesos+marathon. Thanks! 2015-07-16 17:38 GMT+08:00 Peng Zhao : Hi Jay, Yes, we are working with the community to integrate Hyper with Mesos and K8S. Since Hyper uses Pod as the default job unit, it is quite easy to integrate with K8S. Mesos takes a bit more efforts, but still straightforward. We expect to finish both integration in v0.4 early August. Best, Peng
Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper
Thanks Jay. Hongbin, yes, it will be a scheduling system, either swarm, k8s or mesos. I just think bay isn't a must in this case, and we don't need nova to provision BM hosts, which makes things more complicated imo. Peng -- Original -- From: "Jay Lau"; Date: Sun, Jul 19, 2015 10:36 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Hong Bin, I have some online discussion with Peng, seems hyper is now integrating with Kubernetes and also have plan integrate with mesos for scheduling. Once mesos integration finished, we can treat mesos+hyper as another kind of bay. Thanks 2015-07-19 4:15 GMT+08:00 Hongbin Lu : Peng, Several questions Here. You mentioned that HyperStack is a single big “bay”. Then, who is doing the multi-host scheduling, Hyper or something else? Were you suggesting to integrate Hyper with Magnum directly? Or you were suggesting to integrate Hyper with Magnum indirectly (i.e. through k8s, mesos and/or Nova)? Best regards, Hongbin From: Peng Zhao [mailto:p...@hyper.sh] Sent: July-17-15 12:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal with Hyper Hi, Adrian, Jay and all, There could be a much longer version of this, but let me try to explain in a minimalist way. Bay currently has two modes: VM-based, BM-based. In both cases, Bay helps to isolate different tenants' containers. In other words, bay is single-tenancy. For BM-based bay, the single tenancy is a worthy tradeoff, given the performance merits of LXC vs VM. However, for a VM-based bay, there is no performance gain, but single tenancy seems a must, due to the lack of isolation in container. Hyper, as a hypervisor-based substitute for container, brings the much-needed isolation, and therefore enables multi-tenancy. In HyperStack, we don't really need Ironic to provision multiple Hyper bays. On the other hand, the entire HyperStack cluster is a single big "bay". Pretty similar to how Nova works. Also, HyperStack is able to leverage Cinder, Neutron for SDS/SDN functionality. So when someone submits a Docker Compose app, HyperStack would launch HyperVMs and call Cinder/Neutron to setup the volumes and network. The architecture is quite simple. Here are a blog I'd like to recommend: https://hyper.sh/blog/post/2015/06/29/docker-hyper-and-the-end-of-guest-os.html Let me know your questions. Thanks, Peng -- Original -- From: "Adrian Otto"; Date: Thu, Jul 16, 2015 11:02 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwith Hyper Jay, Hyper is a substitute for a Docker host, so I expect it could work equally well for all of the current bay types. Hyper’s idea of a “pod” and a Kubernetes “pod” are similar, but different. I’m not yet convinced that integrating Hyper host creation direct with Magnum (and completely bypassing nova) is a good idea. It probably makes more sense to implement use nova with the ironic dirt driver to provision Hyper hosts so we can use those as substitutes for Bay nodes in our various Bay types. This would fit in the place were we use Fedora Atomic today. We could still rely on nova to do all of the machine instance management and accounting like we do today, but produce bays that use Hyper instead of a Docker host. Everywhere we currently offer CoreOS as an option we could also offer Hyper as an alternative, with some caveats. There may be some caveats/drawbacks to consider before committing to a Hyper integration. I’ll be asking those of Peng also on this thread, so keep an eye out. Thanks, Adrian On Jul 16, 2015, at 3:23 AM, Jay Lau wrote: Thanks Peng, then I can see two integration points for Magnum and Hyper: 1) Once Hyper and k8s integration finished, we can deploy k8s in two mode: docker and hyper mode, the end user can select which mode they want to use. For such case, we do not need to create a new bay but may need some enhancement for current k8s bay 2) After mesos and hyper integration, we can treat mesos and hyper as a new bay to magnum. Just like what we are doing now for mesos+marathon. Thanks! 2015-07-16 17:38 GMT+08:00 Peng Zhao : Hi Jay, Yes, we are working with the community to integrate Hyper with Mesos and K8S. Since Hyper uses Pod as the default job unit, it is quite easy to integrate with K8S. Mesos takes a bit mo
Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal with Hyper
Hi, Adrian, Jay and all, There could be a much longer version of this, but let me try to explain in a minimalist way. Bay currently has two modes: VM-based, BM-based. In both cases, Bay helps to isolate different tenants' containers. In other words, bay is single-tenancy. For BM-based bay, the single tenancy is a worthy tradeoff, given the performance merits of LXC vs VM. However, for a VM-based bay, there is no performance gain, but single tenancy seems a must, due to the lack of isolation in container. Hyper, as a hypervisor-based substitute for container, brings the much-needed isolation, and therefore enables multi-tenancy. In HyperStack, we don't really need Ironic to provision multiple Hyper bays. On the other hand, the entire HyperStack cluster is a single big "bay". Pretty similar to how Nova works. Also, HyperStack is able to leverage Cinder, Neutron for SDS/SDN functionality. So when someone submits a Docker Compose app, HyperStack would launch HyperVMs and call Cinder/Neutron to setup the volumes and network. The architecture is quite simple. Here are a blog I'd like to recommend: https://hyper.sh/blog/post/2015/06/29/docker-hyper-and-the-end-of-guest-os.html Let me know your questions. Thanks, Peng -- Original -- From: "Adrian Otto"; Date: Thu, Jul 16, 2015 11:02 PM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetalwith Hyper Jay, Hyper is a substitute for a Docker host, so I expect it could work equally well for all of the current bay types. Hyper’s idea of a “pod” and a Kubernetes “pod” are similar, but different. I’m not yet convinced that integrating Hyper host creation direct with Magnum (and completely bypassing nova) is a good idea. It probably makes more sense to implement use nova with the ironic dirt driver to provision Hyper hosts so we can use those as substitutes for Bay nodes in our various Bay types. This would fit in the place were we use Fedora Atomic today. We could still rely on nova to do all of the machine instance management and accounting like we do today, but produce bays that use Hyper instead of a Docker host. Everywhere we currently offer CoreOS as an option we could also offer Hyper as an alternative, with some caveats. There may be some caveats/drawbacks to consider before committing to a Hyper integration. I’ll be asking those of Peng also on this thread, so keep an eye out. Thanks, Adrian On Jul 16, 2015, at 3:23 AM, Jay Lau wrote: Thanks Peng, then I can see two integration points for Magnum and Hyper: 1) Once Hyper and k8s integration finished, we can deploy k8s in two mode: docker and hyper mode, the end user can select which mode they want to use. For such case, we do not need to create a new bay but may need some enhancement for current k8s bay 2) After mesos and hyper integration, we can treat mesos and hyper as a new bay to magnum. Just like what we are doing now for mesos+marathon. Thanks! 2015-07-16 17:38 GMT+08:00 Peng Zhao : Hi Jay, Yes, we are working with the community to integrate Hyper with Mesos and K8S. Since Hyper uses Pod as the default job unit, it is quite easy to integrate with K8S. Mesos takes a bit more efforts, but still straightforward. We expect to finish both integration in v0.4 early August. Best, Peng - Hyper - Make VM run like Container On Thu, Jul 16, 2015 at 3:47 PM, Jay Lau wrote: Hi Peng, Just want to get more for Hyper. If we create a hyper bay, then can I set up multiple hosts in a hyper bay? If so, who will do the scheduling, does mesos or some others integrate with hyper? I did not find much info for hyper cluster management. Thanks. 2015-07-16 9:54 GMT+08:00 Peng Zhao : -- Original -- From: “Adrian Otto”; Date: Wed, Jul 15, 2015 02:31 AM To: “OpenStack Development Mailing List (not for usage questions)“; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, On Jul 13, 2015, at 8:37 PM, Peng Zhao wrote: Thanks Adrian! Hi, all, Let me recap what is hyper and the idea of hyperstack. Hyper is a single-host runtime engine. Technically, Docker = LXC + AUFS Hyper = Hypervisor + AUFS where AUFS is the Docker image. I do not understand the last line above. My understanding is that AUFS == UnionFS, which is used to implement a storage driver for Docker. Others exist for btrfs, and devicemapper. You select which one you want by setting an option like this: DOCKEROPTS=”-s devicemapper” Are you trying to say that with Hyper,
Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwith Hyper
Hi Jay, Yes, we are working with the community to integrate Hyper with Mesos and K8S. Since Hyper uses Pod as the default job unit, it is quite easy to integrate with K8S. Mesos takes a bit more efforts, but still straightforward. We expect to finish both integration in v0.4 early August. Best, Peng - Hyper - Make VM run like Container On Thu, Jul 16, 2015 at 3:47 PM, Jay Lau < jay.lau@gmail.com > wrote: Hi Peng, Just want to get more for Hyper. If we create a hyper bay, then can I set up multiple hosts in a hyper bay? If so, who will do the scheduling, does mesos or some others integrate with hyper? I did not find much info for hyper cluster management. Thanks. 2015-07-16 9:54 GMT+08:00 Peng Zhao < p...@hyper.sh > : -- Original -- From: “Adrian Otto”< adrian.otto@rackspace. com >; Date: Wed, Jul 15, 2015 02:31 AM To: “OpenStack Development Mailing List (not for usage questions)“< openstack-dev@ lists.openstack.org >; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, On Jul 13, 2015, at 8:37 PM, Peng Zhao < p...@hyper.sh > wrote: Thanks Adrian! Hi, all, Let me recap what is hyper and the idea of hyperstack. Hyper is a single-host runtime engine. Technically, Docker = LXC + AUFS Hyper = Hypervisor + AUFS where AUFS is the Docker image. I do not understand the last line above. My understanding is that AUFS == UnionFS, which is used to implement a storage driver for Docker. Others exist for btrfs, and devicemapper. You select which one you want by setting an option like this: DOCKEROPTS= ” -s devicemapper ” Are you trying to say that with Hyper, AUFS is used to provide layered Docker image capability that are shared by multiple hypervisor guests? Peng >>> Yes, AUFS implies the Docker images here. My guess is that you are trying to articulate that a host running Hyper is a 1:1 substitute for a host running Docker, and will respond using the Docker remote API. This would result in containers running on the same host that have a superior security isolation than they would if LXC was used as the backend to Docker. Is this correct? Peng>>> Exactly Due to the shared-kernel nature of LXC, Docker lacks of the necessary isolation in a multi-tenant CaaS platform, and this is what Hyper/hypervisor is good at. And because of this, most CaaS today run on top of IaaS: https://trello-attachments.s3. amazonaws.com/ 55545e127c7cbe0ec5b82f2b/ 388x275/ e286dea1266b46c1999d566b0f9e32 6b/iaas.png Hyper enables the native, secure, bare-metal CaaS https://trello-attachments. s3.amazonaws.com/ 55545e127c7cbe0ec5b82f2b/ 395x244/ 828ad577dafb3f357e95899e962651 b2/caas.png >From the tech stack perspective, Hyperstack turns Magnum o run in parallel with Nova, not running on atop. For this to work, we’d expect to get a compute host from Heat, so if the bay type were set to “hyper”, we’d need to use a template that can produce a compute host running Hyper. How would that host be produced, if we do not get it from nova? Might it make more sense to make a dirt driver for nova that could produce a Hyper guest on a host already running the nova-compute agent? That way Magnum would not need to re-create any of Nova’s functionality in order to produce nova instances of type “hyper”. Peng >>> We don’t have to get the physical host from nova. Let’s say OpenStack = Nova+Cinder+Neutron+Bare- metal+KVM, so “AWS-like IaaS for everyone else” HyperStack= Magnum+Cinder+Neutron+Bare- metal+Hyper, then “Google-like CaaS for everyone else” Ideally, customers should deploy a single OpenStack cluster, with both nova/kvm and magnum/hyper. I’m looking for a solution to make nova/magnum co-exist. Is Hyper compatible with libvirt? Peng>>> We are working on the libvirt integration, expect in v0.5 Can Hyper support nested Docker containers within the Hyper guest? Peng>>> Docker in Docker? In a HyperVM instance, there is no docker daemon, cgroup and namespace (except MNT for pod). VM serves the purpose of isolation. We plan to support cgroup and namespace, so you can control whether multiple containers in a pod share the same namespace, or completely isolated. But in either case, no docker daemon is present. Thanks, Adrian Otto Best, Peng -- Original -- From: “Adrian Otto”< adrian.otto@rackspace. com >; Date: Tue, Jul 14, 2015 07:18 AM To: “OpenStack Development Mailing List (not for usage questions)“< openstack-dev@ lists.openstack.org >; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Team, I woud like to ask for your input about adding support for Hyper in Magnum: https://blueprints.launchpad. net/magnum/+spec/hyperstack We touched on this in our last team meeting, and it was apparent that achieving a higher level of understanding of the technology befor
Re: [openstack-dev] [magnum][bp] Power Magnum to run on metalwith Hyper
-- Original -- From: “Adrian Otto”; Date: Wed, Jul 15, 2015 02:31 AM To: “OpenStack Development Mailing List (not for usage questions)“; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, On Jul 13, 2015, at 8:37 PM, Peng Zhao wrote: Thanks Adrian! Hi, all, Let me recap what is hyper and the idea of hyperstack. Hyper is a single-host runtime engine. Technically, Docker = LXC + AUFS Hyper = Hypervisor + AUFS where AUFS is the Docker image. I do not understand the last line above. My understanding is that AUFS == UnionFS, which is used to implement a storage driver for Docker. Others exist for btrfs, and devicemapper. You select which one you want by setting an option like this: DOCKEROPTS=”-s devicemapper” Are you trying to say that with Hyper, AUFS is used to provide layered Docker image capability that are shared by multiple hypervisor guests? Peng >>> Yes, AUFS implies the Docker images here. My guess is that you are trying to articulate that a host running Hyper is a 1:1 substitute for a host running Docker, and will respond using the Docker remote API. This would result in containers running on the same host that have a superior security isolation than they would if LXC was used as the backend to Docker. Is this correct? Peng>>> Exactly Due to the shared-kernel nature of LXC, Docker lacks of the necessary isolation in a multi-tenant CaaS platform, and this is what Hyper/hypervisor is good at. And because of this, most CaaS today run on top of IaaS: https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/388x275/e286dea1266b46c1999d566b0f9e326b/iaas.png Hyper enables the native, secure, bare-metal CaaS https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/395x244/828ad577dafb3f357e95899e962651b2/caas.png From the tech stack perspective, Hyperstack turns Magnum o run in parallel with Nova, not running on atop. For this to work, we’d expect to get a compute host from Heat, so if the bay type were set to “hyper”, we’d need to use a template that can produce a compute host running Hyper. How would that host be produced, if we do not get it from nova? Might it make more sense to make a dirt driver for nova that could produce a Hyper guest on a host already running the nova-compute agent? That way Magnum would not need to re-create any of Nova’s functionality in order to produce nova instances of type “hyper”. Peng >>> We don’t have to get the physical host from nova. Let’s say OpenStack = Nova+Cinder+Neutron+Bare-metal+KVM, so “AWS-like IaaS for everyone else” HyperStack= Magnum+Cinder+Neutron+Bare-metal+Hyper, then “Google-like CaaS for everyone else” Ideally, customers should deploy a single OpenStack cluster, with both nova/kvm and magnum/hyper. I’m looking for a solution to make nova/magnum co-exist. Is Hyper compatible with libvirt? Peng>>> We are working on the libvirt integration, expect in v0.5 Can Hyper support nested Docker containers within the Hyper guest? Peng>>> Docker in Docker? In a HyperVM instance, there is no docker daemon, cgroup and namespace (except MNT for pod). VM serves the purpose of isolation. We plan to support cgroup and namespace, so you can control whether multiple containers in a pod share the same namespace, or completely isolated. But in either case, no docker daemon is present. Thanks, Adrian Otto Best, Peng -- Original -- From: “Adrian Otto”; Date: Tue, Jul 14, 2015 07:18 AM To: “OpenStack Development Mailing List (not for usage questions)“; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Team, I woud like to ask for your input about adding support for Hyper in Magnum: https://blueprints.launchpad.net/magnum/+spec/hyperstack We touched on this in our last team meeting, and it was apparent that achieving a higher level of understanding of the technology before weighing in about the directional approval of this blueprint. Peng Zhao and Xu Wang have graciously agreed to respond to this thread to address questions about how the technology works, and how it could be integrated with Magnum. Please take a moment to review the blueprint, and ask your questions here on this thread. Thanks, Adrian Otto On Jul 2, 2015, at 8:48 PM, Peng Zhao wrote: Here is the bp of Magnum+Hyper+Metal integration: https://blueprints.launchpad.net/magnum/+spec/hyperstack Wanted to hear more thoughts and kickstart some brainstorming. Thanks, Peng - Hyper - Make VM run like Container __ OpenS
[openstack-dev] Fw:Re: [magnum][bp] Power Magnum to run on metal with Hyper
On Wed, Jul 15, 2015 at 6:52 PM, Peng Zhao < p...@hyper.sh > wrote: -- Original -- From: “Adrian Otto”< adrian.otto@rackspace. com >; Date: Wed, Jul 15, 2015 02:31 AM To: “OpenStack Development Mailing List (not for usage questions)“< openstack-dev@ lists.openstack.org >; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run onmetal withHyper Peng, On Jul 13, 2015, at 8:37 PM, Peng Zhao < p...@hyper.sh > wrote: Thanks Adrian! Hi, all, Let me recap what is hyper and the idea of hyperstack. Hyper is a single-host runtime engine. Technically, Docker = LXC + AUFS Hyper = Hypervisor + AUFS where AUFS is the Docker image. I do not understand the last line above. My understanding is that AUFS == UnionFS, which is used to implement a storage driver for Docker. Others exist for btrfs, and devicemapper. You select which one you want by setting an option like this: DOCKEROPTS= ” -s devicemapper ” Are you trying to say that with Hyper, AUFS is used to provide layered Docker image capability that are shared by multiple hypervisor guests? Peng >>> Yes, AUFS implies the Docker images here. My guess is that you are trying to articulate that a host running Hyper is a 1:1 substitute for a host running Docker, and will respond using the Docker remote API. This would result in containers running on the same host that have a superior security isolation than they would if LXC was used as the backend to Docker. Is this correct? Peng>>> Exactly Due to the shared-kernel nature of LXC, Docker lacks of the necessary isolation in a multi-tenant CaaS platform, and this is what Hyper/hypervisor is good at. And because of this, most CaaS today run on top of IaaS: https://trello-attachments.s3. amazonaws.com/ 55545e127c7cbe0ec5b82f2b/ 388x275/ e286dea1266b46c1999d566b0f9e32 6b/iaas.png Hyper enables the native, secure, bare-metal CaaS https://trello-attachments. s3.amazonaws.com/ 55545e127c7cbe0ec5b82f2b/ 395x244/ 828ad577dafb3f357e95899e962651 b2/caas.png >From the tech stack perspective, Hyperstack turns Magnum o run in parallel with Nova, not running on atop. For this to work, we’d expect to get a compute host from Heat, so if the bay type were set to “hyper”, we’d need to use a template that can produce a compute host running Hyper. How would that host be produced, if we do not get it from nova? Might it make more sense to make a dirt driver for nova that could produce a Hyper guest on a host already running the nova-compute agent? That way Magnum would not need to re-create any of Nova’s functionality in order to produce nova instances of type “hyper”. Peng >>> We don’t have to get the physical host from nova. Let’s say OpenStack = Nova+Cinder+Neutron+Bare-metal+KVM, so “AWS-like IaaS for everyone else” HyperStack= Magnum+Cinder+Neutron+Bare-metal+Hyper, then “Google-like CaaS for everyone else” Ideally, customers should deploy a single OpenStack cluster, with both nova/kvm and magnum/hyper. I’m looking for a solution to make nova/magnum co-exist. Is Hyper compatible with libvirt? Peng>>> We are working on the libvirt integration, expect in v0.5 Can Hyper support nested Docker containers within the Hyper guest? Peng>>> Docker in Docker? In a HyperVM instance, there is no docker daemon, cgroup and namespace (except MNT for pod). VM serves the purpose of isolation. We plan to support cgroup and namespace, so you can control whether multiple containers in a pod share the same namespace, or completely isolated. But in either case, no docker daemon is present. Thanks, Adrian Otto Best, Peng -- Original -- From: “Adrian Otto”< adrian.otto@rackspace. com >; Date: Tue, Jul 14, 2015 07:18 AM To: “OpenStack Development Mailing List (not for usage questions)“< openstack-dev@ lists.openstack.org >; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Team, I woud like to ask for your input about adding support for Hyper in Magnum: https://blueprints.launchpad. net/magnum/+spec/hyperstack We touched on this in our last team meeting, and it was apparent that achieving a higher level of understanding of the technology before weighing in about the directional approval of this blueprint. Peng Zhao and Xu Wang have graciously agreed to respond to this thread to address questions about how the technology works, and how it could be integrated with Magnum. Please take a moment to review the blueprint, and ask your questions here on this thread. Thanks, Adrian Otto On Jul 2, 2015, at 8:48 PM, Peng Zhao < p...@hyper.sh > wrote: Here is the bp of Magnum+Hyper+Metal integration: https://blueprints.launchpad. net/magnum/+spec/hyperstack Wanted to hear more thoughts and kickstart some brainstorming. Thanks, Peng -- --- Hyper - Make VM run like Container __ ___
Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper
Thanks Adrian! Hi, all, Let me recap what is hyper and the idea of hyperstack. Hyper is a single-host runtime engine. Technically, Docker = LXC + AUFS Hyper = Hypervisor + AUFS where AUFS is the Docker image. Due to the shared-kernel nature of LXC, Docker lacks of the necessary isolation in a multi-tenant CaaS platform, and this is what Hyper/hypervisor is good at. And because of this, most CaaS today run on top of IaaS: https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/388x275/e286dea1266b46c1999d566b0f9e326b/iaas.png Hyper enables the native, secure, bare-metal CaaS https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/395x244/828ad577dafb3f357e95899e962651b2/caas.png From the tech stack perspective, Hyperstack turns Magnum o run in parallel with Nova, not running on atop. Best, Peng -- Original -- From: "Adrian Otto"; Date: Tue, Jul 14, 2015 07:18 AM To: "OpenStack Development Mailing List (not for usage questions)"; Subject: Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper Team, I woud like to ask for your input about adding support for Hyper in Magnum: https://blueprints.launchpad.net/magnum/+spec/hyperstack We touched on this in our last team meeting, and it was apparent that achieving a higher level of understanding of the technology before weighing in about the directional approval of this blueprint. Peng Zhao and Xu Wang have graciously agreed to respond to this thread to address questions about how the technology works, and how it could be integrated with Magnum. Please take a moment to review the blueprint, and ask your questions here on this thread. Thanks, Adrian Otto On Jul 2, 2015, at 8:48 PM, Peng Zhao wrote: Here is the bp of Magnum+Hyper+Metal integration: https://blueprints.launchpad.net/magnum/+spec/hyperstack Wanted to hear more thoughts and kickstart some brainstorming. Thanks, Peng - Hyper - Make VM run like Container __ 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 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] [magnum][bp] Power Magnum to run on metal with Hyper
Here is the bp of Magnum+Hyper+Metal integration: https://blueprints.launchpad.net/magnum/+spec/hyperstack Wanted to hear more thoughts and kickstart some brainstorming. Thanks, Peng - Hyper - Make VM run like Container__ 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] Proposal of nova-hyper driver
Thanks John. I’m also not sure what the future would be, but I’d say that it would be nice to have a hybrid OpenStack cluster of both VM/App-Container flavor. And yes, it is more about a unified model between Nova and Magnum. Best, Peng - Hyper - Make VM run like Container On Mon, Jun 22, 2015 at 5:10 PM, John Garbutt < j...@johngarbutt.com > wrote: On 22 June 2015 at 09:18, Sahid Orentino Ferdjaoui < sahid.ferdja...@redhat.com > wrote: > On Sun, Jun 21, 2015 at 07:18:10PM +0300, Joe Gordon wrote: >> On Fri, Jun 19, 2015 at 12:55 PM, Peng Zhao wrote: >> >> > Hi, all, >> > >> > I would like to propose nova-hyper driver: >> > https://blueprints.launchpad. net/nova/+spec/nova-hyper . >> > >> > - What is Hyper? >> > Put simply, Hyper is a hypervisor-agnostic Docker runtime. It is >> > similar to Intel’s ClearContainer, allowing to run a Docker image with any >> > hypervisor. >> > >> > - Why Hyper driver? >> > Given its hypervisor nature, Hyper makes it easy to integrate with >> > OpenStack ecosystem, e.g. Nova, Cinder, Neutron >> > >> > - How to implement? >> > Similar to nova-docker driver. Hyper has a daemon “hyperd” running on >> > each physical box. hyperd exposed a set of REST APIs. Integrating Nova with >> > the APIs would do the job. For clarity, we are yet to accept the nova-docker driver into the Nova project, due to various concerns about its potential future direction. Hopefully we should get a more final answer on that soon. >> > - Roadmap >> > Integrate with Magnum & Ironic. >> > >> > >> This sounds like a better fit for something on top of Nova such as Magnum >> then as a Nova driver. +1 On the surface, it feels like a possible Magnum driver. Although I am far from certain that its an exact match. But I think that would be a better starting point than Nova. >> Nova only supports things that look like 'VMs'. That includes bare metal, >> and containers, but it only includes a subset of container features. +1 In your blueprint you mention: "The difference between LXC and VM makes the driver hard to maintain a unified model in Nova." To be clear Nova has no intention of providing a unified model, in part due to the truth behind your statement above. We provide things that look like "servers". Please see: http://docs.openstack.org/ developer/nova/project_scope. html#containers I would recommending talking the container subgroup, in one of their meetings, about how best to integrate with OpenStack: https://wiki.openstack.org/ wiki/Meetings/Containers >> Looking at the hyper CLI [0], there are many commands that nova would not >> suppprt, such as: >> >> * The pod notion >> * exec >> * pull > > Then I guess you need to see if Hyper can implement mandatory features > for Nova [1], [2]. > > [1] http://docs.openstack.org/ developer/nova/support-matrix. html > [2] https://wiki.openstack.org/ wiki/HypervisorSupportMatrix We have no intention of expanding the scope of the Nova API to include container operation. And the reverse is also true, we would want to see an intention to support all the important existing APIs before inclusion, and proving that be having tempest tests reliably passing. Many thanks, John __ __ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@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
Re: [openstack-dev] Proposal of nova-hyper driver
Hyper is using hypervisor to run Docker image, therefore it can support most features in the matrix, both mandatory and optional/choice. - Hyper - Make VM run like Container On Mon, Jun 22, 2015 at 4:18 PM, Sahid Orentino Ferdjaoui < sahid.ferdja...@redhat.com > wrote: On Sun, Jun 21, 2015 at 07:18:10PM +0300, Joe Gordon wrote: > On Fri, Jun 19, 2015 at 12:55 PM, Peng Zhao wrote: > > > Hi, all, > > > > I would like to propose nova-hyper driver: > > https://blueprints.launchpad. net/nova/+spec/nova-hyper . > > > > - What is Hyper? > > Put simply, Hyper is a hypervisor-agnostic Docker runtime. It is > > similar to Intel’s ClearContainer, allowing to run a Docker image with any > > hypervisor. > > > > > > - Why Hyper driver? > > Given its hypervisor nature, Hyper makes it easy to integrate with > > OpenStack ecosystem, e.g. Nova, Cinder, Neutron > > > > - How to implement? > > Similar to nova-docker driver. Hyper has a daemon “hyperd” running on > > each physical box. hyperd exposed a set of REST APIs. Integrating Nova with > > the APIs would do the job. > > > > - Roadmap > > Integrate with Magnum & Ironic. > > > > > This sounds like a better fit for something on top of Nova such as Magnum > then as a Nova driver. > > Nova only supports things that look like 'VMs'. That includes bare metal, > and containers, but it only includes a subset of container features. > > Looking at the hyper CLI [0], there are many commands that nova would not > suppprt, such as: > > * The pod notion > * exec > * pull Then I guess you need to see if Hyper can implement mandatory features for Nova [1], [2]. [1] http://docs.openstack.org/ developer/nova/support-matrix. html [2] https://wiki.openstack.org/ wiki/HypervisorSupportMatrix > [0] https://docs.hyper.sh/ reference/cli.html > > > > > Appreciate for comments and inputs! > > Thanks,Peng > > > > -- --- > > Hyper - Make VM run like Container > > > > > > __ __ __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request@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@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@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
[openstack-dev] Proposal of nova-hyper driver
Hi, all, I would like to propose nova-hyper driver: https://blueprints.launchpad.net/nova/+spec/nova-hyper . * What is Hyper? Put simply, Hyper is a hypervisor-agnostic Docker runtime. It is similar to Intel’s ClearContainer, allowing to run a Docker image with any hypervisor. * Why Hyper driver? Given its hypervisor nature, Hyper makes it easy to integrate with OpenStack ecosystem, e.g. Nova, Cinder, Neutron * How to implement? Similar to nova-docker driver. Hyper has a daemon “hyperd” running on each physical box. hyperd exposed a set of REST APIs. Integrating Nova with the APIs would do the job. * Roadmap Integrate with Magnum & Ironic. Appreciate for comments and inputs! Thanks,Peng - Hyper - Make VM run like Container__ 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
