<div dir="ltr"><div class="gmail_default" style="font-size:12.8px;font-family:tahoma,sans-serif">Joshua,</div><div class="gmail_default" style="font-size:12.8px;font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-size:12.8px;font-family:tahoma,sans-serif">I think the current boundary (COE, bay) is introduced mostly because of the lack of isolation in container, rather than management isolation.</div><div class="gmail_default" style="font-size:12.8px;font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-size:12.8px;font-family:tahoma,sans-serif">Therefore, if we could isolate different tenants' containers (hyper.sh), we don't have to run separate COEs for each tenant, baking the multi-tenancy feature into COE should be fine.</div><div class="gmail_default" style="font-size:12.8px;font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-size:12.8px;font-family:tahoma,sans-serif">And, I think operating a single COE at scale is do-able (just look at AWS ECS and Google Container Engine). At the very least, if we can run a single Nova, Ceph, Neutron for a large OpenStack cluster, we should be able to run a single k8s/mesos/swarm as well.</div><div class="gmail_default" style="font-size:12.8px;font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-size:12.8px;font-family:tahoma,sans-serif">Peng</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 1, 2015 at 6:55 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Totally get it,<br>
<br>
And its interesting the boundaries that are being pushed,<br>
<br>
Also interesting to know the state of the world, and the state of magnum<br>
and the state of COE systems. I'm somewhat surprised that they lack<br>
multi-tenancy in any kind of manner (but I guess I'm not to surprised,<br>
its a feature that many don't add-on until later, for better or<br>
worse...), especially kubernetes (coming from google), but not entirely<br>
shocked by it ;-)<br>
<br>
Insightful stuff, thanks :)<br>
<div><div class="h5"><br>
Steven Dake (stdake) wrote:<br>
> Joshua,<br>
><br>
> If you share resources, you give up multi-tenancy.  No COE system has the<br>
> concept of multi-tenancy (kubernetes has some basic implementation but it<br>
> is totally insecure).  Not only does multi-tenancy have to “look like” it<br>
> offers multiple tenants isolation, but it actually has to deliver the<br>
> goods.<br>
><br>
> I understand that at first glance a company like Yahoo may not want<br>
> separate bays for their various applications because of the perceived<br>
> administrative overhead.  I would then challenge Yahoo to go deploy a COE<br>
> like kubernetes (which has no multi-tenancy or a very basic implementation<br>
> of such) and get it to work with hundreds of different competing<br>
> applications.  I would speculate the administrative overhead of getting<br>
> all that to work would be greater then the administrative overhead of<br>
> simply doing a bay create for the various tenants.<br>
><br>
> Placing tenancy inside a COE seems interesting, but no COE does that<br>
> today.  Maybe in the future they will.  Magnum was designed to present an<br>
> integration point between COEs and OpenStack today, not five years down<br>
> the road.  Its not as if we took shortcuts to get to where we are.<br>
><br>
> I will grant you that density is lower with the current design of Magnum<br>
> vs a full on integration with OpenStack within the COE itself.  However,<br>
> that model which is what I believe you proposed is a huge design change to<br>
> each COE which would overly complicate the COE at the gain of increased<br>
> density.  I personally don’t feel that pain is worth the gain.<br>
><br>
> Regards,<br>
> -steve<br>
><br>
><br>
> On 9/30/15, 2:18 PM, "Joshua Harlow"<<a href="mailto:harlowja@outlook.com">harlowja@outlook.com</a>>  wrote:<br>
><br>
>> Wouldn't that limit the ability to share/optimize resources then and<br>
>> increase the number of operators needed (since each COE/bay would need<br>
>> its own set of operators managing it)?<br>
>><br>
>> If all tenants are in a single openstack cloud, and under say a single<br>
>> company then there isn't much need for management isolation (in fact I<br>
>> think said feature is actually a anti-feature in a case like this).<br>
>> Especially since that management is already by keystone and the<br>
</div></div>>> project/tenant&  user associations and such there.<br>
<div class="HOEnZb"><div class="h5">>><br>
>> Security isolation I get, but if the COE is already multi-tenant aware<br>
>> and that multi-tenancy is connected into the openstack tenancy model,<br>
>> then it seems like that point is nil?<br>
>><br>
>> I get that the current tenancy boundary is the bay (aka the COE right?)<br>
>> but is that changeable? Is that ok with everyone, it seems oddly matched<br>
>> to say a company like yahoo, or other private cloud, where one COE would<br>
>> I think be preferred and tenancy should go inside of that; vs a eggshell<br>
>> like solution that seems like it would create more management and<br>
>> operability pain (now each yahoo internal group that creates a bay/coe<br>
>> needs to figure out how to operate it? and resources can't be shared<br>
>> and/or orchestrated across bays; hmmmm, seems like not fully using a COE<br>
>> for what it can do?)<br>
>><br>
>> Just my random thoughts, not sure how much is fixed in stone.<br>
>><br>
>> -Josh<br>
>><br>
>> Adrian Otto wrote:<br>
>>> Joshua,<br>
>>><br>
>>> The tenancy boundary in Magnum is the bay. You can place whatever<br>
>>> single-tenant COE you want into the bay (Kubernetes, Mesos, Docker<br>
>>> Swarm). This allows you to use native tools to interact with the COE in<br>
>>> that bay, rather than using an OpenStack specific client. If you want to<br>
>>> use the OpenStack client to create both bays, pods, and containers, you<br>
>>> can do that today. You also have the choice, for example, to run kubctl<br>
>>> against your Kubernetes bay, if you so desire.<br>
>>><br>
>>> Bays offer both a management and security isolation between multiple<br>
>>> tenants. There is no intent to share a single bay between multiple<br>
>>> tenants. In your use case, you would simply create two bays, one for<br>
>>> each of the yahoo-mail.XX tenants. I am not convinced that having an<br>
>>> uber-tenant makes sense.<br>
>>><br>
>>> Adrian<br>
>>><br>
>>>> On Sep 30, 2015, at 1:13 PM, Joshua Harlow<<a href="mailto:harlowja@outlook.com">harlowja@outlook.com</a><br>
>>>> <mailto:<a href="mailto:harlowja@outlook.com">harlowja@outlook.com</a>>>  wrote:<br>
>>>><br>
>>>> Adrian Otto wrote:<br>
>>>>> Thanks everyone who has provided feedback on this thread. The good<br>
>>>>> news is that most of what has been asked for from Magnum is actually<br>
>>>>> in scope already, and some of it has already been implemented. We<br>
>>>>> never aimed to be a COE deployment service. That happens to be a<br>
>>>>> necessity to achieve our more ambitious goal: We want to provide a<br>
>>>>> compelling Containers-as-a-Service solution for OpenStack clouds in a<br>
>>>>> way that offers maximum leverage of what’s already in OpenStack,<br>
>>>>> while giving end users the ability to use their favorite tools to<br>
>>>>> interact with their COE of choice, with the multi-tenancy capability<br>
>>>>> we expect from all OpenStack services, and simplified integration<br>
>>>>> with a wealth of existing OpenStack services (Identity,<br>
>>>>> Orchestration, Images, Networks, Storage, etc.).<br>
>>>>><br>
>>>>> The areas we have disagreement are whether the features offered for<br>
>>>>> the k8s COE should be mirrored in other COE’s. We have not attempted<br>
>>>>> to do that yet, and my suggestion is to continue resisting that<br>
>>>>> temptation because it is not aligned with our vision. We are not here<br>
>>>>> to re-invent container management as a hosted service. Instead, we<br>
>>>>> aim to integrate prevailing technology, and make it work great with<br>
>>>>> OpenStack. For example, adding docker-compose capability to Magnum is<br>
>>>>> currently out-of-scope, and I think it should stay that way. With<br>
>>>>> that said, I’m willing to have a discussion about this with the<br>
>>>>> community at our upcoming Summit.<br>
>>>>><br>
>>>>> An argument could be made for feature consistency among various COE<br>
>>>>> options (Bay Types). I see this as a relatively low value pursuit.<br>
>>>>> Basic features like integration with OpenStack Networking and<br>
>>>>> OpenStack Storage services should be universal. Whether you can<br>
>>>>> present a YAML file for a bay to perform internal orchestration is<br>
>>>>> not important in my view, as long as there is a prevailing way of<br>
>>>>> addressing that need. In the case of Docker Bays, you can simply<br>
>>>>> point a docker-compose client at it, and that will work fine.<br>
>>>>><br>
>>>> So an interesting question, but how is tenancy going to work, will<br>
>>>> there be a keystone tenancy<->  COE tenancy adapter? From my<br>
>>>> understanding a whole bay (COE?) is owned by a tenant, which is great<br>
>>>> for tenants that want to ~experiment~ with a COE but seems disjoint<br>
>>>> from the end goal of an integrated COE where the tenancy model of both<br>
>>>> keystone and the COE is either the same or is adapted via some adapter<br>
>>>> layer.<br>
>>>><br>
>>>> For example:<br>
>>>><br>
>>>> 1) Bay that is connected to uber-tenant 'yahoo'<br>
>>>><br>
>>>> 1.1) Pod inside bay that is connected to tenant '<a href="http://yahoo-mail.us" rel="noreferrer" target="_blank">yahoo-mail.us</a><br>
>>>> <<a href="http://yahoo-mail.us/" rel="noreferrer" target="_blank">http://yahoo-mail.us/</a>>'<br>
>>>> 1.2) Pod inside bay that is connected to tenant '<a href="http://yahoo-mail.in" rel="noreferrer" target="_blank">yahoo-mail.in</a>'<br>
>>>> ...<br>
>>>><br>
>>>> All those tenancy information is in keystone, not replicated/synced<br>
>>>> into the COE (or in some other COE specific disjoint system).<br>
>>>><br>
>>>> Thoughts?<br>
>>>><br>
>>>> This one becomes especially hard if said COE(s) don't even have a<br>
>>>> tenancy model in the first place :-/<br>
>>>><br>
>>>>> Thanks,<br>
>>>>><br>
>>>>> Adrian<br>
>>>>><br>
>>>>>> On Sep 30, 2015, at 8:58 AM, Devdatta<br>
>>>>>> Kulkarni<<a href="mailto:devdatta.kulkarni@RACKSPACE.COM">devdatta.kulkarni@RACKSPACE.COM</a><br>
>>>>>> <mailto:<a href="mailto:devdatta.kulkarni@RACKSPACE.COM">devdatta.kulkarni@RACKSPACE.COM</a>>>  wrote:<br>
>>>>>><br>
>>>>>> +1 Hongbin.<br>
>>>>>><br>
>>>>>>  From perspective of Solum, which hopes to use Magnum for its<br>
>>>>>> application container scheduling requirements, deep integration of<br>
>>>>>> COEs with OpenStack services like Keystone will be useful.<br>
>>>>>> Specifically, I am thinking that it will be good if Solum can<br>
>>>>>> depend on Keystone tokens to deploy and schedule containers on the<br>
>>>>>> Bay nodes instead of having to use COE specific credentials. That<br>
>>>>>> way, container resources will become first class components that<br>
>>>>>> can be monitored using Ceilometer, access controlled using<br>
>>>>>> Keystone, and managed from within Horizon.<br>
>>>>>><br>
>>>>>> Regards, Devdatta<br>
>>>>>><br>
>>>>>><br>
>>>>>> From: Hongbin Lu<<a href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a><br>
>>>>>> <mailto:<a href="mailto:hongbin.lu@huawei.com">hongbin.lu@huawei.com</a>>>  Sent: Wednesday, September<br>
>>>>>> 30, 2015 9:44 AM To: OpenStack Development Mailing List (not for<br>
>>>>>> usage questions) Subject: Re: [openstack-dev] [magnum]swarm +<br>
>>>>>> compose = k8s?<br>
>>>>>><br>
>>>>>><br>
>>>>>> +1 from me as well.<br>
>>>>>><br>
>>>>>> I think what makes Magnum appealing is the promise to provide<br>
>>>>>> container-as-a-service. I see coe deployment as a helper to achieve<br>
>>>>>> the promise, instead of the main goal.<br>
>>>>>><br>
>>>>>> Best regards, Hongbin<br>
>>>>>><br>
>>>>>><br>
>>>>>> From: Jay Lau [mailto:<a href="mailto:jay.lau.513@gmail.com">jay.lau.513@gmail.com</a>] Sent: September-29-15<br>
>>>>>> 10:57 PM To: OpenStack Development Mailing List (not for usage<br>
>>>>>> questions) Subject: Re: [openstack-dev] [magnum]swarm + compose =<br>
>>>>>> k8s?<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> +1 to Egor, I think that the final goal of Magnum is container as a<br>
>>>>>> service but not coe deployment as a service. ;-)<br>
>>>>>><br>
>>>>>> Especially we are also working on Magnum UI, the Magnum UI should<br>
>>>>>> export some interfaces to enable end user can create container<br>
>>>>>> applications but not only coe deployment.<br>
>>>>>><br>
>>>>>> I hope that the Magnum can be treated as another "Nova" which is<br>
>>>>>> focusing on container service. I know it is difficult to unify all<br>
>>>>>> of the concepts in different coe (k8s has pod, service, rc, swarm<br>
>>>>>> only has container, nova only has VM, PM with different<br>
>>>>>> hypervisors), but this deserve some deep dive and thinking to see<br>
>>>>>> how can move forward.....<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Wed, Sep 30, 2015 at 1:11 AM, Egor Guz<<a href="mailto:EGuz@walmartlabs.com">EGuz@walmartlabs.com</a><br>
>>>>>> <mailto:<a href="mailto:EGuz@walmartlabs.com">EGuz@walmartlabs.com</a>>><br>
>>>>>> wrote: definitely ;), but the are some thoughts to Tom’s email.<br>
>>>>>><br>
>>>>>> I agree that we shouldn't reinvent apis, but I don’t think Magnum<br>
>>>>>> should only focus at deployment (I feel we will become another<br>
>>>>>> Puppet/Chef/Ansible module if we do it ):) I belive our goal should<br>
>>>>>> be seamlessly integrate Kub/Mesos/Swarm to OpenStack ecosystem<br>
>>>>>> (Neutron/Cinder/Barbican/etc) even if we need to step in to<br>
>>>>>> Kub/Mesos/Swarm communities for that.<br>
>>>>>><br>
>>>>>> — Egor<br>
>>>>>><br>
>>>>>> From: Adrian<br>
>>>>>> Otto<<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a><br>
>>>>>> <mailto:<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><mailto:<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>>><br>
>>>>>> Reply-To: "OpenStack Development Mailing List (not for usage<br>
>>>>>> questions)"<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><mailto:<a href="mailto:openstack-dev@lists">openstack-dev@lists</a>.<br>
>>>>>> <a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a>>><br>
>>>>>><br>
>>>>>><br>
>>>> Date: Tuesday, September 29, 2015 at 08:44<br>
>>>>>> To: "OpenStack Development Mailing List (not for usage<br>
>>>>>> questions)"<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><mailto:<a href="mailto:openstack-dev@lists">openstack-dev@lists</a>.<br>
>>>>>> <a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a>>><br>
>>>>>><br>
>>>>>><br>
>>>> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?<br>
>>>>>> This is definitely a topic we should cover in Tokyo.<br>
>>>>>><br>
>>>>>> On Sep 29, 2015, at 8:28 AM, Daneyon Hansen<br>
>>>>>> (danehans)<<a href="mailto:danehans@cisco.com">danehans@cisco.com</a><br>
>>>>>> <mailto:<a href="mailto:danehans@cisco.com">danehans@cisco.com</a>><mailto:<a href="mailto:danehans@cisco.com">danehans@cisco.com</a>>>  wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>> +1<br>
>>>>>><br>
>>>>>> From: Tom Cammann<<a href="mailto:tom.cammann@hpe.com">tom.cammann@hpe.com</a><br>
>>>>>> <mailto:<a href="mailto:tom.cammann@hpe.com">tom.cammann@hpe.com</a>><mailto:<a href="mailto:tom.cammann@hpe.com">tom.cammann@hpe.com</a>>><br>
>>>>>> Reply-To:<br>
>>>>>> "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><mailto:<a href="mailto:openstack-dev@lists">openstack-dev@lists</a>.<br>
>>>>>> <a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a>>"<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><mailto:<a href="mailto:openstack-dev@lists">openstack-dev@lists</a>.<br>
>>>>>> <a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a>>><br>
>>>>>><br>
>>>>>><br>
>>>> Date: Tuesday, September 29, 2015 at 2:22 AM<br>
>>>>>> To:<br>
>>>>>> "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><mailto:<a href="mailto:openstack-dev@lists">openstack-dev@lists</a>.<br>
>>>>>> <a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a>>"<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><mailto:<a href="mailto:openstack-dev@lists">openstack-dev@lists</a>.<br>
>>>>>> <a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a>>><br>
>>>>>><br>
>>>>>><br>
>>>> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?<br>
>>>>>> This has been my thinking in the last couple of months to<br>
>>>>>> completely deprecate the COE specific APIs such as pod/service/rc<br>
>>>>>> and container.<br>
>>>>>><br>
>>>>>> As we now support Mesos, Kubernetes and Docker Swarm its going to<br>
>>>>>> be very difficult and probably a wasted effort trying to<br>
>>>>>> consolidate their separate APIs under a single Magnum API.<br>
>>>>>><br>
>>>>>> I'm starting to see Magnum as COEDaaS - Container Orchestration<br>
>>>>>> Engine Deployment as a Service.<br>
>>>>>><br>
>>>>>> On 29/09/15 06:30, Ton Ngo wrote: Would it make sense to ask the<br>
>>>>>> opposite of Wanghua's question: should pod/service/rc be deprecated<br>
>>>>>> if the user can easily get to the k8s api? Even if we want to<br>
>>>>>> orchestrate these in a Heat template, the corresponding heat<br>
>>>>>> resources can just interface with k8s instead of Magnum. Ton Ngo,<br>
>>>>>><br>
>>>>>> <ATT00001.gif>Egor Guz ---09/28/2015 10:20:02 PM---Also I belive<br>
>>>>>> docker compose is just command line tool which doesn’t have any api<br>
>>>>>> or scheduling feat<br>
>>>>>><br>
>>>>>> From: Egor Guz<<a href="mailto:EGuz@walmartlabs.com">EGuz@walmartlabs.com</a><br>
>>>>>> <mailto:<a href="mailto:EGuz@walmartlabs.com">EGuz@walmartlabs.com</a>>><mailto:<a href="mailto:EGuz@walmartlabs.com">EGuz@walmartlabs.com</a>><br>
>>>>>> To:<br>
>>>>>> "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>"<mailto:<a href="mailto:openstack-dev@lists">openstack-dev@lists</a><br>
>>>>>> .<a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a>><br>
>>>>>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><mailto:<a href="mailto:openstack-dev@lists">openstack-dev@lists</a><br>
>>>>>> .<a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a>><br>
>>>>>><br>
>>>>>><br>
>>>> Date: 09/28/2015 10:20 PM<br>
>>>>>> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?<br>
>>>>>> ________________________________<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Also I belive docker compose is just command line tool which<br>
>>>>>> doesn’t have any api or scheduling features. But during last Docker<br>
>>>>>> Conf hackathon PayPal folks implemented docker compose executor for<br>
>>>>>> Mesos (<a href="https://github.com/mohitsoni/compose-executor" rel="noreferrer" target="_blank">https://github.com/mohitsoni/compose-executor</a>) which can<br>
>>>>>> give you pod like experience.<br>
>>>>>><br>
>>>>>> — Egor<br>
>>>>>><br>
>>>>>> From: Adrian<br>
>>>>>> Otto<<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><mailto:<a href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a>><m<br>
>>>>>> <a href="mailto:ailto%3Aadrian.otto@rackspace.com">ailto:adrian.otto@rackspace.com</a>>><br>
>>>>>><br>
>>>>>><br>
>>>> Reply-To: "OpenStack Development Mailing List (not for usage<br>
>>>> questions)"<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>>>><br>
>>>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><mailto:<a href="mailto:openstack-dev@lists.op">openstack-dev@lists.op</a><br>
>>>> <a href="http://enstack.org" rel="noreferrer" target="_blank">enstack.org</a>><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
>>>>>> Date: Monday, September 28, 2015 at 22:03 To: "OpenStack<br>
>>>>>> Development Mailing List (not for usage<br>
>>>>>> questions)"<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><mailto:<a href="mailto:openstack-dev@lists">openstack-dev@lists</a>.<br>
>>>>>> <a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a>><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
>>>>>><br>
>>>>>><br>
>>>> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?<br>
>>>>>> Wanghua,<br>
>>>>>><br>
>>>>>> I do follow your logic, but docker-compose only needs the docker<br>
>>>>>> API to operate. We are intentionally avoiding re-inventing the<br>
>>>>>> wheel. Our goal is not to replace docker swarm (or other existing<br>
>>>>>> systems), but to compliment it/them. We want to offer users of<br>
>>>>>> Docker the richness of native APIs and supporting tools. This way<br>
>>>>>> they will not need to compromise features or wait longer for us to<br>
>>>>>> implement each new feature as it is added. Keep in mind that our<br>
>>>>>> pod, service, and replication controller resources pre-date this<br>
>>>>>> philosophy. If we started out with the current approach, those<br>
>>>>>> would not exist in Magnum.<br>
>>>>>><br>
>>>>>> Thanks,<br>
>>>>>><br>
>>>>>> Adrian<br>
>>>>>><br>
>>>>>> On Sep 28, 2015, at 8:32 PM, 王华<br>
>>>>>> <<a href="mailto:wanghua.humble@gmail.com">wanghua.humble@gmail.com</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:wanghua.humble@gmail.com">wanghua.humble@gmail.com</a>><mailto:<a href="mailto:wanghua.humble@gmail.com">wanghua.humble@gmail.com</a>><mai<br>
>>>>>> <a href="mailto:lto%3Awanghua.humble@gmail.com">lto:wanghua.humble@gmail.com</a>>><br>
>>>>>> wrote:<br>
>>>>>><br>
>>>>>> Hi folks,<br>
>>>>>><br>
>>>>>> Magnum now exposes service, pod, etc to users in kubernetes coe,<br>
>>>>>> but exposes container in swarm coe. As I know, swarm is only a<br>
>>>>>> scheduler of container, which is like nova in openstack. Docker<br>
>>>>>> compose is a orchestration program which is like heat in openstack.<br>
>>>>>> k8s is the combination of scheduler and orchestration. So I think<br>
>>>>>> it is better to expose the apis in compose to users which are at<br>
>>>>>> the same level as k8s.<br>
>>>>>><br>
>>>>>><br>
>>>>>> Regards Wanghua<br>
>>>>>><br>
>>>>>> ______________________________________________________________________<br>
>>>>>> ____<br>
>>>>>><br>
>>>>>><br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>> Unsubscribe:<br>
>>>>>> <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>><mailto:<a href="mailto:OpenStack-de">OpenStack-de</a><br>
>>>>>> <a href="mailto:v-request@lists.openstack.org">v-request@lists.openstack.org</a>><mailto:<a href="mailto:OpenStack-dev-request@lists.open">OpenStack-dev-request@lists.open</a><br>
>>>>>> <a href="http://stack.org" rel="noreferrer" target="_blank">stack.org</a>>?subject:unsubscribe<br>
>>>>>><br>
>>>>>><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>> ______________________________________________________________________<br>
>>>>>> ____<br>
>>>>>><br>
>>>>>><br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>> Unsubscribe:<br>
>>>>>> <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe><br>
>>>>>><br>
>>>>>><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> ______________________________________________________________________<br>
>>>>>> ____<br>
>>>>>><br>
>>>>>><br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>> Unsubscribe:<br>
>>>>>> <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>> <ATT00001.gif>__________________________________________________________<br>
>>>> ________________<br>
>>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>><br>
>>>>>><br>
>>>>>> Unsubscribe:<br>
>>>>>> <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>><mailto:<a href="mailto:OpenStack-de">OpenStack-de</a><br>
>>>>>> <a href="mailto:v-request@lists.openstack.org">v-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>>>><br>
>>>>>><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>> ______________________________________________________________________<br>
>>>>>> ____<br>
>>>>>><br>
>>>>>><br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>> Unsubscribe:<br>
>>>>>> <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> --<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> Thanks, Jay Lau (Guangya Liu)<br>
>>>>>><br>
>>>>>><br>
>>>>>> ______________________________________________________________________<br>
>>>>>> ____<br>
>>>>>><br>
>>>>>><br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>>> Unsubscribe:<br>
>>>>>> <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>>><br>
>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>> _______________________________________________________________________<br>
>>>>> ___<br>
>>>>><br>
>>>>><br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
>>>>> <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>>> ________________________________________________________________________<br>
>>>> __<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> <a href="mailto:Unsubscribe%3AOpenStack-dev-request@lists.openstack.org">Unsubscribe:OpenStack-dev-request@lists.openstack.org</a><br>
>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>> _________________________________________________________________________<br>
>>> _<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>