Open Stack

Its new enough that people haven't thought to ask until recently. The recent interest is starting in the topic due to Magnum getting mature enough folks are starting to deploy it and finding out it doesn't solve a bunch of issues they had thought it would. Its pretty natural. Don't just blow it off because you haven't been asked till now.

I know we're going to try and pilot it here soon, and the only reason I know some of these things that we will need coming up aren't there now is I've paid close attention to the dev mailing list. Others don't pay so close attention.

Thanks,
Kevin
________________________________________
From: Hongbin Lu [hongbin.lu at huawei.com]
Sent: Wednesday, April 20, 2016 4:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

> -----Original Message-----
> From: Keith Bray [mailto:keith.bray at RACKSPACE.COM]
> Sent: April-20-16 6:13 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum][app-catalog][all] Build unified
> abstraction for all COEs
>
> Magnum doesn¹t have to preclude tight integration for single COEs you
> speak of.  The heavy lifting of tight integration of the COE in to
> OpenStack (so that it performs optimally with the infra) can be modular
> (where the work is performed by plug-in models to Magnum, not performed
> by Magnum itself. The tight integration can be done by leveraging
> existing technologies (Heat and/or choose your DevOps tool of choice:
> Chef/Ansible/etc). This allows interested community members to focus on
> tight integration of whatever COE they want, focusing specifically on

I agree that tight integration can be achieved by a plugin, but I think the key question is who will do the work. If tight integration needs to be done, I wonder why it is not part of the Magnum efforts. From my point of view, pushing the work out doesn't seem to address the original pain, which is some users don't want to explore the complexities of individual COEs.

> the COE integration part, contributing that integration focus to Magnum
> via plug-ins, without having to actually know much about Magnum, but
> instead
> contribute to the COE plug-in using DevOps tools of choice.   Pegging
> Magnum to one-and-only one COE means there will be a Magnum2, Magnum3,
> etc. project for every COE of interest, all with different ways of
> kicking off COE management.  Magnum could unify that experience for
> users and operators, without picking a winner in the COE space < this
> is just like Nova not picking a winner between VM flavors or OS types.
> It just facilitates instantiation and management of thins.  Opinion
> here:  The value of Magnum is in being a light-weight/thin API,
> providing modular choice and plug-ability to COE provisioning and
> management, thereby providing operators and users choice of COE
> instantiation and management (via the bay concept), where each COE can
> be as tightly or loosely integrated as desired by different plug-ins
> contributed to perform the COE setup and configurations.  So, Magnum
> could have two or more swarm plug-in options contributed to the
> community.. One overlays generic swarm on VMs.
> The other swarm plug-in could instantiate swarm tightly integrated to
> neutron, keystone, etc on to bare metal.  Magnum just facilities a
> plug-in model with thin API to offer choice of CEO instantiation and
> management.
> The plug-in does the heavy lifting using whatever methods desired by
> the curator.
>
> That¹s my $0.2.
>
> -Keith
>
> On 4/20/16, 4:49 PM, "Joshua Harlow" <harlowja at fastmail.com> wrote:
>
> >Thierry Carrez wrote:
> >> Adrian Otto wrote:
> >>> This pursuit is a trap. Magnum should focus on making native
> >>> container APIs available. We should not wrap APIs with leaky
> >>> abstractions. The lowest common denominator of all COEs is an
> >>> remarkably low value API that adds considerable complexity to
> Magnum
> >>> that will not strategically advance OpenStack. If we instead focus
> >>> our effort on making the COEs work better on OpenStack, that would
> >>> be a winning strategy. Support and compliment our various COE
> ecosystems.
> >
> >So I'm all for avoiding 'wrap APIs with leaky abstractions' and
> 'making
> >COEs work better on OpenStack' but I do dislike the part about COEs
> >(plural) because it is once again the old non-opinionated problem that
> >we (as a community) suffer from.
> >
> >Just my 2 cents, but I'd almost rather we pick one COE and integrate
> >that deeply/tightly with openstack, and yes if this causes some part
> of
> >the openstack community to be annoyed, meh, to bad. Sadly I have a
> >feeling we are hurting ourselves by continuing to try to be everything
> >and not picking anything (it's a general thing we, as a group, seem to
> >be good at, lol). I mean I get the reason to just support all the
> >things, but it feels like we as a community could just pick something,
> >work together on figuring out how to pick one, using all these bright
> >leaders we have to help make that possible (and yes this might piss
> >some people off, to bad). Then work toward making that something great
> >and move on...
> >
> >>
> >> I'm with Adrian on that one. I've attended a lot of
> >> container-oriented conferences over the past year and my main
> >> takeaway is that this new crowd of potential users is not interested
> >> (at all) in an OpenStack-specific lowest common denominator API for
> >> COEs. They want to take advantage of the cool features in Kubernetes
> >> API or the versatility of Mesos. They want to avoid caring about the
> >> infrastructure provider bit (and not deploy Mesos or Kubernetes
> themselves).
> >>
> >> Let's focus on the infrastructure provider bit -- that is what we do
> >> and what the ecosystem wants us to provide.
> >>
> >
> >______________________________________________________________________
> _
> >___ 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
>
>
> _______________________________________________________________________
> ___
> 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

__________________________________________________________________________
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