Open Stack

*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 <EGuz at walmartlabs.com
> <mailto:EGuz at 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.otto at rackspace.com
>     <mailto:adrian.otto at rackspace.com><mailto:adrian.otto at rackspace.com
>     <mailto:adrian.otto at rackspace.com>>>
>     Reply-To: "OpenStack Development Mailing List (not for usage
>     questions)" <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>>
>     Date: Tuesday, September 29, 2015 at 08:44
>     To: "OpenStack Development Mailing List (not for usage questions)"
>     <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at 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)
>     <danehans at cisco.com
>     <mailto:danehans at cisco.com><mailto:danehans at cisco.com
>     <mailto:danehans at cisco.com>>> wrote:
>
>
>     +1
>
>     From: Tom Cammann <tom.cammann at hpe.com
>     <mailto:tom.cammann at hpe.com><mailto:tom.cammann at hpe.com
>     <mailto:tom.cammann at hpe.com>>>
>     Reply-To: "openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>"
>     <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>>
>     Date: Tuesday, September 29, 2015 at 2:22 AM
>     To: "openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>"
>     <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at 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,
>
>     <ATT00001.gif>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 <EGuz at walmartlabs.com
>     <mailto:EGuz at walmartlabs.com>><mailto:EGuz at walmartlabs.com
>     <mailto:EGuz at walmartlabs.com>>
>     To: "openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>"<mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>
>     <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at 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.otto at rackspace.com
>     <mailto:adrian.otto at rackspace.com><mailto:adrian.otto at rackspace.com
>     <mailto:adrian.otto at rackspace.com>><mailto:adrian.otto at rackspace.com
>     <mailto:adrian.otto at rackspace.com>>>
>     Reply-To: "OpenStack Development Mailing List (not for usage
>     questions)" <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>>
>     Date: Monday, September 28, 2015 at 22:03
>     To: "OpenStack Development Mailing List (not for usage questions)"
>     <openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>><mailto:openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>>>
>     Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?
>
>     Wanghua,
>
>     I do follow your logic, but docker-compose only needs the docker API
>     to operate. We are intentionally avoiding re-inventing the wheel.
>     Our goal is not to replace docker swarm (or other existing systems),
>     but to compliment it/them. We want to offer users of Docker the
>     richness of native APIs and supporting tools. This way they will not
>     need to compromise features or wait longer for us to implement each
>     new feature as it is added. Keep in mind that our pod, service, and
>     replication controller resources pre-date this philosophy. If we
>     started out with the current approach, those would not exist in Magnum.
>
>     Thanks,
>
>     Adrian
>
>     On Sep 28, 2015, at 8:32 PM, 王华 <wanghua.humble at gmail.com
>     <mailto:wanghua.humble at gmail.com><mailto:wanghua.humble at gmail.com
>     <mailto:wanghua.humble at gmail.com>><mailto:wanghua.humble at gmail.com
>     <mailto:wanghua.humble at gmail.com>>> wrote:
>
>     Hi folks,
>
>     Magnum now exposes service, pod, etc to users in kubernetes coe, but
>     exposes container in swarm coe. As I know, swarm is only a scheduler
>     of container, which is like nova in openstack. Docker compose is a
>     orchestration program which is like heat in openstack. k8s is the
>     combination of scheduler and orchestration. So I think it is better
>     to expose the apis in compose to users which are at the same level
>     as k8s.
>
>
>     Regards
>     Wanghua
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe: OpenStack-dev-request at lists.openstack.org
>     <mailto:OpenStack-dev-request at lists.openstack.org><mailto:OpenStack-dev-request at lists.openstack.org
>     <mailto:OpenStack-dev-request at lists.openstack.org>><mailto:OpenStack-dev-request at lists.openstack.org
>     <mailto:OpenStack-dev-request at lists.openstack.org>>?subject:unsubscribe
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><mailto:OpenStack-dev-request at lists.openstack.org
>     <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><mailto:OpenStack-dev-request at lists.openstack.org
>     <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>     <ATT00001.gif>__________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe: OpenStack-dev-request at lists.openstack.org
>     <mailto:OpenStack-dev-request at lists.openstack.org><mailto:OpenStack-dev-request at lists.openstack.org
>     <mailto:OpenStack-dev-request at lists.openstack.org>>?subject:unsubscribe
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Thanks,
>
> Jay Lau (Guangya Liu)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>