[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