On Thu, Nov 3, 2016 at 4:29 AM, Vikas Choudhary <choudharyvika...@gmail.com> wrote: > > > 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?
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-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 > __________________________________________________________________________ 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
