[openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs

Antoni Segura Puimedon toni+openstackml at midokura.com
Fri Apr 22 13:53:39 UTC 2016


On Thu, Apr 21, 2016 at 9:30 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> +1.
> ________________________________________
> From: Hongbin Lu [hongbin.lu at huawei.com]
> Sent: Thursday, April 21, 2016 7:50 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: 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.

The integration is being done in the COEs themselves.

In Docker with Swarm you can just do:

    docker network create -d kuryr \
       --ipam-driver=kuryr \
       --subnet=10. 10.0.0/24 \
       --gateway=10.10.0.1 \
       -o neutron.net.name=mynet mynet_d

You can also refer to them by uuid. People are starting to join to be
able to do the same with storage volumes (we'll talk about it in [1])

For Kubernetes we still do not have it upstream, but we create and use
neutron resources as well. All this in bare-metal, but in the newton
cycle, provided that the vlan-aware-vms spec gets released, we'll
support container-in-vm (we'll discuss it in the summit in work
sessions and in a presentation [2]) and Magnum will be able to use it.

So, the way I look at it, Magnum should probably not be too
opinionated, giving choice to operators, but it should provide as much
access to the core OpenStack resources as possible, as long as those
are available in the COE (and that's where we are trying to help).

[1] https://www.openstack.org/summit/austin-2016/summit-schedule/events/6861
[2] https://www.openstack.org/summit/austin-2016/summit-schedule/events/7633


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



More information about the OpenStack-dev mailing list