[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>
>> 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
>> Kuryr - Magnum joint work session
>> * Consensus on using Keystone trust tokens.
>> - We should follow closely the Keystone effort into scoping the
>> actions per token to limit those to the minimal required set of
>> 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
>> 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
>> 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
>> networking the containers would all be in the same Neutron network as
>> ports of their VMs.
>> The problem with this solution is that allowing multiple isolated
>> like CNM and Kubernetes with policy have is quite complicated.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev