Operating System: All
Platform: All

https://git.opendaylight.org/gerrit/21794 shows that this isn't a bug with NN but an issue in openstack/devstack

(output from Jenkins build:

2015-06-03 16:52:32,054 | INFO | qtp736031520-81 | NeutronNetworkDummyProvider | 258 - org.opendaylight.neutron.dummyprovider - 0.5.0.SNAPSHOT | NeutronNetwork [networkUUID=4e8e5957-649f-477b-9e5b-f1f75b21c03c, networkName=net1, adminStateUp=true, shared=false, tenantID=9bacb3c5d39d41a79512987f338cf177, routerExternal=false, providerNetworkType=flat, providerPhysicalNetwork=null, providerSegmentationID=null, status=ACTIVE, subnets=[], myPorts=[], segments = [NeutronNetwork_Segment [ , providerNetworkType=vlan, providerPhysicalNetwork=8bab8453-1bc9-45af-8c70-f83aa9b50453, providerSegmentationID=2], NeutronNetwork_Segment [ , providerNetworkType=stt, providerPhysicalNetwork=8bab8453-1bc9-45af-8c70-f83aa9b50453, providerSegmentationID=null]]]
2015-06-03 16:52:32,179 | INFO | qtp736031520-81 | NeutronSubnetDummyProvider | 258 - org.opendaylight.neutron.dummyprovider - 0.5.0.SNAPSHOT | NeutronSubnet [subnetUUID=3b80198d-4f7b-4f77-9ef5-774d54e17126, networkUUID=4e8e5957-649f-477b-9e5b-f1f75b21c03c, name=, ipVersion=4, cidr=10.0.0.0/24, gatewayIP=10.0.0.1, dnsNameservers=[], allocationPools=[NeutronSubnetIPAllocationPool [start=10.0.0.2, end=10.0.0.254]], hostRoutes=[], enableDHCP=true, tenantID=9bacb3c5d39d41a79512987f338cf177, myPorts=[], gatewayIPAssigned=false, ipv6AddressMode=null, ipv6RaMode=null]
2015-06-03 16:52:32,229 | INFO | qtp736031520-81 | NeutronPortDummyProvider | 258 - org.opendaylight.neutron.dummyprovider - 0.5.0.SNAPSHOT | NeutronPort [portUUID=65c0ee9f-d634-4522-8954-51021b570b0d, networkUUID=4e8e5957-649f-477b-9e5b-f1f75b21c03c, name=private-port, adminStateUp=true, status=DOWN, macAddress=fa:16:3e:c9:cb:f0, fixedIPs=[Neutron_IPs

], deviceID=, deviceOwner=, tenantID=9bacb3c5d39d41a79512987f338cf177, floatingIPMap={}, securityGroups=[NeutronSecurityGroup{securityGroupUUID='null', securityGroupName='null', securityGroupDescription='null', securityGroupTenantID='null', securityRules=null]], bindinghostID=, bindingvnicType=normal, bindingvnicType=normal]
)

I have chased this back... and here's what I've found.

OpenDaylight is not getting tenant_id in this case because our ML2 OpenStack Driver is sending "tenant_id":"".

Our ML2 Driver is sending "tenant_id":"" because that's what ML2 is sending to it.

ML2 is sending "tenant_id":"" because the neutron cli commands are sending "tenant_id":"" to the OpenStack neutron NB.

Which is to say, this looks like its either a bug in the neutron cli commands, or a problem with how they are being used (I honestly don't know which yet).

Reopening/Reassigning to external component for tracking

I would love to hear from a neutron (openstack) guru on this, but at the time the neutron port created for the floating ip is instantiated, it has no association with any tenants [1], yet.

Once floating ip is created [2] is that tenant id info is available within
neutron, but if you look at [2], that is still not associated with the neutron port object.

Only when internal<->external ip association happens is that the mapping of
port happens, but there seems to be no neutron port update being sent to ODL.

See this email thread for more info on obtaining this data:

https://lists.opendaylight.org/pipermail/neutron-dev/2015-June/000180.html

===

[1]: example of a neutron port create just before floating ip is created:

POST /controller/nb/v2/neutron/ports/
{
"port": {
"binding:host_id": "",
"allowed_address_pairs": [],
"device_owner": "network:floatingip",
"port_security_enabled": false,
"binding:profile": {},
"fixed_ips": [

],
"id": "01671703-695e-4497-8a11-b5da989d2dc3",
"security_groups": [],
"device_id": "f013bef4-9468-494d-9417-c9d9e4abb97c",
"name": "",
"admin_state_up": true,
"network_id": "7da709ff-397f-4778-a0e8-994811272fdb",
"tenant_id": "", <==== missing tenant id!
"binding:vif_details": {},
"binding:vnic_type": "normal",
"binding:vif_type": "unbound",
"mac_address": "FA:16:3E:3F:37:BB"
}
}

===

[2]: floating ip creation

POST /controller/nb/v2/neutron/floatingips
{
"floatingip":

}

===

[3]: floating ip association

PUT /controller/nb/v2/neutron/floatingips/f013bef4-9468-494d-9417-c9d9e4abb97c
{
"floatingip":

}

Wait...

The port is scoped by the network - if the network is not shared, then by definition, the port must be in the same tenant as the network.
In that case, it is possible to infer the port's tenant id value.

(In reply to Ryan Moats from comment #5)
> Wait...
>
> The port is scoped by the network - if the network is not shared, then by
> definition, the port must be in the same tenant as the network.
> In that case, it is possible to infer the port's tenant id value.

you are correct. In my poor example, this is not a shared network,
so openstack neutron should be able to get the tenant based on the
network.

in cases when net is shared, this is a bit harder. It is good to point
out that the attribute referred as "port_id" in the floating ip
object is referring to the neutron port used by the 'fixed' address, not
the 'floating-ip' address.

All in all, we are in complete agreement that it should be possible to
have the tenant-id populated – as long as the network is not shared.

tenant_id=''(empty string) is intentionally passed by neutron l3 code.
It seems quick hack. I filed it to sort them out.

https://bugs.launchpad.net/neutron/+bug/1464806
https://bugs.launchpad.net/networking-odl/+bug/1464807

As near term work around, tenant_id can deduced from network object.

Supplement.
Actually Neutron passes tenant_id as ''(empty string), not UUID.
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/l3_db.py#n924

Is this acceptable by ODL side?
Or should it be UUID?

No, an empty tenant ID is not acceptable, neutron northbound expects a valid tenant UUID in this field

With the merged done by Isaku [1], I suspect ODL will no longer get
empty tenant id.

[1]: https://review.openstack.org/#/c/191471/

A floating-ip port contains tenant-id after this commit https://review.openstack.org/#/c/191471/