On Thu, Nov 3, 2016 at 12:33 AM, Antoni Segura Puimedon <celeb...@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? > 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
