[NEUTRON-202] tenant-id not present in response from neutron nb for /networks/network/${UUID} Created: 16/Oct/18  Updated: 29/Aug/19

Status: Confirmed
Project: neutron
Component/s: None
Affects Version/s: None
Fix Version/s: Oxygen-SR4, Fluorine-SR2, Neon

Type: Bug Priority: Medium
Reporter: Jamo Luhrsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

csit job that failed on this

 Not sure how reproducible this is, and haven't come across it more than once while
browsing CSIT results. But, maybe it's more common than we know, and maybe it's
something obvious we can figure out in the logs

the problem request and response looks like this:

GET /restconf/config/neutron:neutron/networks/network/9336700e-077a-4209-b88d-8a94ad1ab441/

resp:
{"network":[{"uuid":"9336700e-077a-4209-b88d-8a94ad1ab441","admin-state-up":true,"neutron-provider-ext:segmentation-id":"1076","neutron-provider-ext:network-type":"neutron-networks:network-type-vxlan","neutron-L3-ext:external":false,"shared":false,"revision-number":2,"name":"vpn_net_1"}]}

as an example of output our CSIT is expecting:

{"network":[{"uuid":"1b1172d0-8fd4-4b71-a7d7-5d81fd81b322","admin-state-up":true,"neutron-provider-ext:segmentation-id":"1001","neutron-provider-ext:network-type":"neutron-networks:network-type-vxlan","tenant-id":"b9f05034-9221-4e03-9e97-2467d7ffa9dd","neutron-L3-ext:external":false,"shared":false,"revision-number":2,"name":"vpn_net_1"}]}


 Comments   
Comment by Michael Vorburger [ 15/Nov/18 ]

I've just briefly looked into this; so NeutronNetworksNorthbound's showNetwork() will ultimately, indirectly (phew) return a NeutronNetwork ... that obviously does have a tenantID (see @XmlElement(name = "tenant_id") on getTenantID() - BTW I don't get what replaces the _ with - to make it tenant-id) - but there was a recent change exactly there, related to NEUTRON-159, see Gerrit Reviews linked from that.

There are tests that cover this though, and they don't fail, so... hm, curious.

Comment by Michael Vorburger [ 15/Nov/18 ]

The CSIT test failure logs linked above are from Sep 22nd, and NEUTRON-159's stuff went in mid Sep - just to check that it's not older, so this could indeed be related... jluhrsen just to double chek, you're implying that it worked earlier? Is it still broken right now? On all branches, Oxygen, Fluorine and Neon?

Comment by Michael Vorburger [ 15/Nov/18 ]

> There are tests that cover this though, and they don't fail, so... hm, curious.

specifically the NeutronNetworkTests, although... on a closer look, I'm not entirely convinced that test really properly covers (validates and assert on) the response - does it? If that's missing, then NEUTRON-159 could have broken things withouts this being picked up in any of those tests - worth a closer look.

PS: The test creates networks using tenant_id - again _ not - so what's it with that diff? Not just tenant, but all.

Comment by Jamo Luhrsen [ 16/Nov/18 ]

I think you missed one critical part of the description that I only found it once
while scouring CSIT results (back in mid Sep). I haven't seen it before or
since, although I am not looking at every single job that runs. I filed the
jira in the hopes that it might be something easy to figure out with the logs,
but it sounds like it's not. Feel free to close this as unreproducible and we
can re-open later.

Comment by Michael Vorburger [ 16/Nov/18 ]

Oh, I see. Let me do one thing - I still want to double check that NeutronNetworkTests actually checks for Tenant ID in the response, and if that is fine, I'll close this.. (In fact, if you don't see it anymore, it's possible that NEUTRON-159 had actually FIXED this problem, not caused it; but I'm not crystal clear on the exact time line involved here.)

Generated at Wed Feb 07 20:25:49 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.