Open Stack

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 < mordred at 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 < 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 racksp ace.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.op enstack.org ><mailto: openstack- dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.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.op enstack.org ><mailto: openstack- dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.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 ><ma ilto: 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 ><m ailto: tom.cammann at hpe.com
<mailto: tom.cammann at hpe.com >>>
Reply-To: “ openstack-dev at lists.openstack .org
<mailto: openstack-dev at lists.op enstack.org ><mailto: openstack- dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.org >>”
< openstack-dev at lists.openstack .org
<mailto: openstack-dev at lists.op enstack.org ><mailto: openstack- dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.org >>>
Date: Tuesday, September 29, 2015 at 2:22 AM
To: “ openstack-dev at lists.openstack .org
<mailto: openstack-dev at lists.op enstack.org ><mailto: openstack- dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.org >>”
< openstack-dev at lists.openstack .org
<mailto: openstack-dev at lists.op enstack.org ><mailto: openstack- dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.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.op enstack.org >“<mailto: openstack -dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.org >>
< openstack-dev at lists.openstack .org
<mailto: openstack-dev at lists.op enstack.org >><mailto: openstack -dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.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 racksp ace.com
<mailto: adrian.otto at rackspace. com >><mailto: adrian.otto at racks pace.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.op enstack.org ><mailto: openstack- dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.org >><mailto: openstack -dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.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.op enstack.org ><mailto: openstack- dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.org >><mailto: openstack -dev at lists.openstack.org
<mailto: openstack-dev at lists.op enstack.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.c om ><mailto: wanghua.humble at gmai l.com
<mailto: wanghua.humble at gmail.c om >><mailto: wanghua.humble at gma il.com
<mailto: wanghua.humble at gmail.c om >>> 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.op enstack.org
<mailto: OpenStack-dev-request@ lists.openstack.org ><mailto: Op enStack-dev-request at lists.open stack.org
<mailto: OpenStack-dev-request@ lists.openstack.org >><mailto: O penStack-dev-request at lists.ope nstack.org
<mailto: OpenStack-dev-request@ lists.openstack.org >>?subject: unsubscribe
http://lists.openstack.org/cgi -bin/mailman/listinfo/openstac k-dev
______________________________ ______________________________ ______________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request at lists.op enstack.org?subject:unsubscrib e
< http://OpenStack-dev-request@ lists.openstack.org?subject:un subscribe ><mailto: OpenStack-de v-request at lists.openstack.org
<mailto: OpenStack-dev-request@ lists.openstack.org >?subject:u nsubscribe>
http://lists.openstack.org/cgi -bin/mailman/listinfo/openstac k-dev





______________________________ ______________________________ ______________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request at lists.op enstack.org?subject:unsubscrib e
< http://OpenStack-dev-request@ lists.openstack.org?subject:un subscribe ><mailto: OpenStack-de v-request at lists.openstack.org
<mailto: OpenStack-dev-request@ lists.openstack.org >?subject:u nsubscribe> http://lists.openst ack.org/cgi-bin/mailman/listin fo/openstack-dev

<ATT00001.gif>________________ ______________________________ ____________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.op enstack.org
<mailto: OpenStack-dev-request@ lists.openstack.org ><mailto: Op enStack-dev-request at lists.open stack.org
<mailto: OpenStack-dev-request@ lists.openstack.org >>?subject: unsubscribe
http://lists.openstack.org/cgi -bin/mailman/listinfo/openstac k-dev

______________________________ ______________________________ ______________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request at lists.op enstack.org?subject:unsubscrib e
< http://OpenStack-dev-request@ lists.openstack.org?subject:un subscribe >
http://lists.openstack.org/cgi -bin/mailman/listinfo/openstac k-dev




--
Thanks,

Jay Lau (Guangya Liu)


______________________________ ______________________________ ______________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at 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-request at lists.op enstack.org?subject:unsubscrib e
http://lists.openstack.org/cgi -bin/mailman/listinfo/openstac k-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150930/f1960a14/attachment-0001.html>