Open Stack

> -----Original Message-----
> From: Steve Gordon [mailto:sgordon at redhat.com]
> Sent: April-21-16 9:39 AM
> 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: "Hongbin Lu" <hongbin.lu at huawei.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > > -----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.
> 
> Why does the integration belong in Magnum though? To me it belongs in
> the COEs themselves (e.g. their in-tree network/storage plugins) such
> that someone can leverage them regardless of their choices regarding
> COE deployment tooling (and yes that means Magnum should be able to
> leverage them too)? I guess the issue is that in the above conversation
> we are overloading the term "integration" which can be taken to mean
> different things...

I can clarify. I mean to introduce abstractions to allow tight integration between COEs and OpenStack. For example,

$ magnum container-create --volume=<cinder volume> --net=<neutron network> ...

I agree with you that such integration should be supported by the COEs themselves. If it does, Magnum will leverage it (anyone can leverage it as well regardless of they are using Magnum or not). If it doesn't (the reality), Magnum could add support for that via its abstraction layer. For your question about why such integration belongs in Magnum, my answer is that the work needs to be done in one place so that everyone can leverage it instead of re-inventing their own solutions. Magnum is the OpenStack container service so it is nature for Magnum to take it IMHO.

> 
> -Steve
> 
> > 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.
> 
> 
> _______________________________________________________________________
> ___
> 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