Open Stack

The work on the plug-ins can still be done by Magnum core contributors (or
anyone). My point is that the work doesn’t have to be code-coupled to
Magnum except via the plug-in interface, which, like heat resources,
should be relatively straight forward. Creating the plug-in framework in
this way allows for leverage of work by non-Magnum contributors and re-use
of Chef/Ansible/Heat/PickYourFavoriteHere tool for infra configuration and
orchestration.  

-Keith

On 4/20/16, 6:03 PM, "Hongbin Lu" <hongbin.lu at huawei.com> wrote:

>
>
>> -----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