<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 01 Mar 2016, at 06:22, Kevin Benton <<a href="mailto:kevin@benton.pub" class="">kevin@benton.pub</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">><span style="font-size:12.8px" class="">This seems gross and backwards. It makes sense as a short term hack but given that we have time to design this correctly I'd prefer to get this information in a more straighforward way.</span><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">Well it depends on what is happening here. If Manilla is wiring up a specific VLAN for a port, that makes it part of the port binding process, in which case it should be an ML2 driver. Can you provide some more details about what Manilla is doing with this info?</span></div></div></div></blockquote><div><br class=""></div><div><div>The VLAN segment ID and IP address is used in the share driver to configure the</div><div>corresponding interface resources within the storage. Just to give some</div><div>examples:</div><div><br class=""></div><div> - NetApp driver uses it to create a logical interface and assign it to a</div><div>   “storage virtual machine” [1]</div><div> - EMC driver does it in similar manner [2]</div><div><br class=""></div><div>My idea was to use the same principle as ironic ml2 intregration is doing [3]</div><div>by setting the vnic_type to “baremetal”.</div><div><br class=""></div><div>In Manila's current implementation storage drivers are also responsible to</div><div>setup the right networking setup. Would you suggest to move this part into the</div><div>port binding phase?</div><div><br class=""></div><div>Regards</div><div>Marc</div></div><div><br class=""></div><div><br class=""></div><div>[1]: <a href="https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272" class="">https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272</a></div><div>[2]: <a href="https://github.com/openstack/manila/blob/master/manila/share/drivers/emc/plugins/vnx/connection.py#L609" class="">https://github.com/openstack/manila/blob/master/manila/share/drivers/emc/plugins/vnx/connection.py#L609</a></div><div>[3]: <a href="https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html" class="">https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html</a></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Feb 29, 2016 at 5:29 PM, Ben Swartzlander <span dir="ltr" class=""><<a href="mailto:ben@swartzlander.org" target="_blank" class="">ben@swartzlander.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/29/2016 04:38 PM, Kevin Benton wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You're correct. Right now there is no way via the HTTP API to find which<br class="">
segments a port is bound to.<br class="">
This is something we can certainly consider adding, but it will need an<br class="">
RFE so it wouldn't land until Newton at the earliest.<br class="">
</blockquote>
<br class=""></span>
I believe Newton is the target for this work. This is feature freeze week after all.<span class=""><br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Have you considered writing an ML2 driver that just notifies Manilla of<br class="">
the port's segment info? All of this information is available to ML2<br class="">
drivers in the PortContext object that is passed to them.<br class="">
</blockquote>
<br class=""></span>
This seems gross and backwards. It makes sense as a short term hack but given that we have time to design this correctly I'd prefer to get this information in a more straighforward way.<br class="">
<br class="">
-Ben Swartzlander<br class="">
<br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Mon, Feb 29, 2016 at 6:48 AM, Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com" target="_blank" class="">ihrachys@redhat.com</a><br class=""></span><span class="">
<mailto:<a href="mailto:ihrachys@redhat.com" target="_blank" class="">ihrachys@redhat.com</a>>> wrote:<br class="">
<br class="">
    Fixed neutron tag in the subject.<br class="">
<br class=""></span><div class=""><div class="h5">
    Marc <<a href="mailto:marc@koderer.com" target="_blank" class="">marc@koderer.com</a> <mailto:<a href="mailto:marc@koderer.com" target="_blank" class="">marc@koderer.com</a>>> wrote:<br class="">
<br class="">
        Hi Neutron team,<br class="">
<br class="">
        I am currently working on a feature for hierarchical port<br class="">
        binding support in<br class="">
        Manila [1] [2]. Just to give some context: In the current<br class="">
        implementation Manila<br class="">
        creates a neutron port but let it unbound (state DOWN).<br class="">
        Therefore Manila uses<br class="">
        the port create only retrieve an IP address and segmentation ID<br class="">
        (some drivers<br class="">
        only support VLAN here).<br class="">
<br class="">
        My idea is to change this behavior and do an actual port binding<br class="">
        action so that<br class="">
        the configuration of VLAN isn’t a manual job any longer. And<br class="">
        that multi-segment<br class="">
        and HPB is supported on the long-run.<br class="">
<br class="">
        My current issue is: How can Manila retrieve the segment<br class="">
        information for a<br class="">
        bound port? Manila only is interested in the last (bottom)<br class="">
        segmentation ID<br class="">
        since I assume the storage is connected to a ToR switch.<br class="">
<br class="">
        Database-wise it’s possible to query it using<br class="">
        ml2_port_binding_levels table.<br class="">
        But AFAIK there is no API to query this. The only information<br class="">
        that is exposed<br class="">
        are all segments of a network. But this is not sufficient to<br class="">
        identify which<br class="">
        segments actually used for a port binding.<br class="">
<br class="">
        Regards<br class="">
        Marc<br class="">
        SAP SE<br class="">
<br class="">
        [1]:<br class="">
        <a href="https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support" rel="noreferrer" target="_blank" class="">https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support</a><br class="">
        [2]: <a href="https://review.openstack.org/#/c/277731/" rel="noreferrer" target="_blank" class="">https://review.openstack.org/#/c/277731/</a><br class="">
        __________________________________________________________________________<br class="">
        OpenStack Development Mailing List (not for usage questions)<br class="">
        Unsubscribe:<br class="">
        <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class=""></div></div>
        <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><br class="">
        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
<br class="">
<br class="">
<br class="">
    __________________________________________________________________________<br class="">
    OpenStack Development Mailing List (not for usage questions)<br class="">
    Unsubscribe:<br class="">
    <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class=""></span>
    <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><br class="">
    <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
<br class="">
<br class="">
<br class="">
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
<br class="">
</span></blockquote><div class="HOEnZb"><div class="h5">
<br class="">
<br class="">
__________________________________________________________________________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="">
</div></div></blockquote></div><br class=""></div>
__________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""></body></html>