[openstack-dev] [kuryr][magnum] Notes from Summit fishbowl session

Antoni Segura Puimedon celebdor at gmail.com
Thu Nov 3 09:20:40 UTC 2016


On Thu, Nov 3, 2016 at 4:29 AM, Vikas Choudhary
<choudharyvikas16 at gmail.com> wrote:
>
>
> On Thu, Nov 3, 2016 at 12:33 AM, Antoni Segura Puimedon <celebdor at gmail.com>
> wrote:
>>
>> Hi magna and kuryrs!
>>
>> Thank you all for joining last week meetings. I am now writing a few
>> emails to have persistent notes of what was talked about and discussed
>> in the Kuryr work sessions. In the Magnum joint session the points
>> were:
>>
>>     Kuryr - Magnum joint work session
>>     =================================
>>
>>     Authentication
>>     ==============
>>
>>     * Consensus on using Keystone trust tokens.
>>         - We should follow closely the Keystone effort into scoping the
>> allowed
>>           actions per token to limit those to the minimal required set of
>> verbs
>>           that the COE and Kuryr need.
>>
>>     * It was deemed unnecessary to pursue a proxying approach to access
>>       Neutron. This means VM applications should be able to reach Neutron
>> and
>>       Keystone but the only source of credentials they should have is the
>>       Keystone tokens.
>>
>>
>>     Tenancy and network topology
>>     ============================
>>
>>     Two approaches should be made available to users:
>>
>>     Full Neutron networking
>>     ~~~~~~~~~~~~~~~~~~~~~~~
>>
>>     Under this configuration, containers running inside the nova instances
>>     would get networking via Neutron vlan-aware-VMs feature. This means
>> the COE
>>     driver (either kuryr-libnetwork or kuryr-kubernetes) would request a
>>     Neutron subport for the container. In this way, there can be multiple
>>     isolated networks running on worker nodes.
>>
>>     The concerns about this solution are about the performance when
>> starting
>>     big amounts of containers and the latency introduced when starting
>> them due
>>     to going all the way to Neutron to request the subport.
>>
>>     Minimal Neutron networking
>>     ~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>
> Is this ipvlan/macvlan approach?

Yes. This will use ipvlan/macvlan.

>
>>
>>     In order to address the concerns with the 'Full Neutron networking'
>>     approach, and as a trade-off between features and minimalism, this way
>> of
>>     networking the containers would all be in the same Neutron network as
>> the
>>     ports of their VMs.
>>
>>     The problem with this solution is that allowing multiple isolated
>> networks
>>     like CNM and Kubernetes with policy have is quite complicated.
>>
>>
>> Regards,
>>
>> Toni
>>
>> __________________________________________________________________________
>> 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