<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 3, 2016 at 12:33 AM, Antoni Segura Puimedon <span dir="ltr"><<a href="mailto:celebdor@gmail.com" target="_blank">celebdor@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi magna and kuryrs!<br>
<br>
Thank you all for joining last week meetings. I am now writing a few<br>
emails to have persistent notes of what was talked about and discussed<br>
in the Kuryr work sessions. In the Magnum joint session the points<br>
were:<br>
<br>
    Kuryr - Magnum joint work session<br>
    ==============================<wbr>===<br>
<br>
    Authentication<br>
    ==============<br>
<br>
    * Consensus on using Keystone trust tokens.<br>
        - We should follow closely the Keystone effort into scoping the allowed<br>
          actions per token to limit those to the minimal required set of verbs<br>
          that the COE and Kuryr need.<br>
<br>
    * It was deemed unnecessary to pursue a proxying approach to access<br>
      Neutron. This means VM applications should be able to reach Neutron and<br>
      Keystone but the only source of credentials they should have is the<br>
      Keystone tokens.<br>
<br>
<br>
    Tenancy and network topology<br>
    ============================<br>
<br>
    Two approaches should be made available to users:<br>
<br>
    Full Neutron networking<br>
    ~~~~~~~~~~~~~~~~~~~~~~~<br>
<br>
    Under this configuration, containers running inside the nova instances<br>
    would get networking via Neutron vlan-aware-VMs feature. This means the COE<br>
    driver (either kuryr-libnetwork or kuryr-kubernetes) would request a<br>
    Neutron subport for the container. In this way, there can be multiple<br>
    isolated networks running on worker nodes.<br>
<br>
    The concerns about this solution are about the performance when starting<br>
    big amounts of containers and the latency introduced when starting them due<br>
    to going all the way to Neutron to request the subport.<br>
<br>
    Minimal Neutron networking<br>
    ~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
<br></blockquote><div> </div><div>Is this ipvlan/macvlan approach?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    In order to address the concerns with the 'Full Neutron networking'<br>
    approach, and as a trade-off between features and minimalism, this way of<br>
    networking the containers would all be in the same Neutron network as the<br>
    ports of their VMs.<br>
<br>
    The problem with this solution is that allowing multiple isolated networks<br>
    like CNM and Kubernetes with policy have is quite complicated.<br>
<br>
<br>
Regards,<br>
<br>
Toni<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div></div>