[openstack-dev] [magnum]swarm + compose = k8s?
Adrian Otto
adrian.otto at rackspace.com
Wed Sep 30 20:38:38 UTC 2015
Joshua,
The tenancy boundary in Magnum is the bay. You can place whatever single-tenant COE you want into the bay (Kubernetes, Mesos, Docker Swarm). This allows you to use native tools to interact with the COE in that bay, rather than using an OpenStack specific client. If you want to use the OpenStack client to create both bays, pods, and containers, you can do that today. You also have the choice, for example, to run kubctl against your Kubernetes bay, if you so desire.
Bays offer both a management and security isolation between multiple tenants. There is no intent to share a single bay between multiple tenants. In your use case, you would simply create two bays, one for each of the yahoo-mail.XX tenants. I am not convinced that having an uber-tenant makes sense.
Adrian
On Sep 30, 2015, at 1:13 PM, Joshua Harlow <harlowja at outlook.com<mailto:harlowja at outlook.com>> wrote:
Adrian Otto wrote:
Thanks everyone who has provided feedback on this thread. The good
news is that most of what has been asked for from Magnum is actually
in scope already, and some of it has already been implemented. We
never aimed to be a COE deployment service. That happens to be a
necessity to achieve our more ambitious goal: We want to provide a
compelling Containers-as-a-Service solution for OpenStack clouds in a
way that offers maximum leverage of what’s already in OpenStack,
while giving end users the ability to use their favorite tools to
interact with their COE of choice, with the multi-tenancy capability
we expect from all OpenStack services, and simplified integration
with a wealth of existing OpenStack services (Identity,
Orchestration, Images, Networks, Storage, etc.).
The areas we have disagreement are whether the features offered for
the k8s COE should be mirrored in other COE’s. We have not attempted
to do that yet, and my suggestion is to continue resisting that
temptation because it is not aligned with our vision. We are not here
to re-invent container management as a hosted service. Instead, we
aim to integrate prevailing technology, and make it work great with
OpenStack. For example, adding docker-compose capability to Magnum is
currently out-of-scope, and I think it should stay that way. With
that said, I’m willing to have a discussion about this with the
community at our upcoming Summit.
An argument could be made for feature consistency among various COE
options (Bay Types). I see this as a relatively low value pursuit.
Basic features like integration with OpenStack Networking and
OpenStack Storage services should be universal. Whether you can
present a YAML file for a bay to perform internal orchestration is
not important in my view, as long as there is a prevailing way of
addressing that need. In the case of Docker Bays, you can simply
point a docker-compose client at it, and that will work fine.
So an interesting question, but how is tenancy going to work, will there be a keystone tenancy <-> COE tenancy adapter? From my understanding a whole bay (COE?) is owned by a tenant, which is great for tenants that want to ~experiment~ with a COE but seems disjoint from the end goal of an integrated COE where the tenancy model of both keystone and the COE is either the same or is adapted via some adapter layer.
For example:
1) Bay that is connected to uber-tenant 'yahoo'
1.1) Pod inside bay that is connected to tenant 'yahoo-mail.us<http://yahoo-mail.us/>'
1.2) Pod inside bay that is connected to tenant 'yahoo-mail.in'
...
All those tenancy information is in keystone, not replicated/synced into the COE (or in some other COE specific disjoint system).
Thoughts?
This one becomes especially hard if said COE(s) don't even have a tenancy model in the first place :-/
Thanks,
Adrian
On Sep 30, 2015, at 8:58 AM, Devdatta
Kulkarni<devdatta.kulkarni at RACKSPACE.COM<mailto:devdatta.kulkarni at RACKSPACE.COM>> wrote:
+1 Hongbin.
From perspective of Solum, which hopes to use Magnum for its
application container scheduling requirements, deep integration of
COEs with OpenStack services like Keystone will be useful.
Specifically, I am thinking that it will be good if Solum can
depend on Keystone tokens to deploy and schedule containers on the
Bay nodes instead of having to use COE specific credentials. That
way, container resources will become first class components that
can be monitored using Ceilometer, access controlled using
Keystone, and managed from within Horizon.
Regards, Devdatta
From: Hongbin Lu<hongbin.lu at huawei.com<mailto:hongbin.lu at huawei.com>> Sent: Wednesday, September
30, 2015 9:44 AM To: OpenStack Development Mailing List (not for
usage questions) Subject: Re: [openstack-dev] [magnum]swarm +
compose = k8s?
+1 from me as well.
I think what makes Magnum appealing is the promise to provide
container-as-a-service. I see coe deployment as a helper to achieve
the promise, instead of the main goal.
Best regards, Hongbin
From: Jay Lau [mailto:jay.lau.513 at gmail.com] Sent: September-29-15
10:57 PM To: OpenStack Development Mailing List (not for usage
questions) Subject: Re: [openstack-dev] [magnum]swarm + compose =
k8s?
+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>>
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>>
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>>
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>> wrote:
+1
From: Tom Cammann<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>"<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>"<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>
To:
"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>
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>>
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: 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>>
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>>
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>?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<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe<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<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe<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>?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<mailto:OpenStack-dev-request at 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<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<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<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150930/da5cf3f4/attachment-0001.html>
More information about the OpenStack-dev
mailing list