© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Hi Rodolfo,
thank you for your answer and the hint for the meeting.
> The tuple you provided won't prevent the DB to register a segment with the same physical network and network type.
That's true, but preventing duplicate segments-ids for the same physical network is part of the VlanTypeDriver. So I think in general it should be part of the SegmentTypeDriver [4] implementation and doesn't need validation here.
The problem with adding segmentation_id into the tuple is, that it doesn't solve the problem we see in production.
Let me give an example for a problematic configuration:
1: network_id | physical_network | network_type | segmentation_id
2: a | b | c | 1000
3: a | b | c | 1200
4: d | b | c | 1300
5: d | f | c | 1300
6: a | b | e |
You see in lines 2 and 3, the segmentation_id is not the same. The VlanTypeDriver takes care of that. But we now have multiple VLANs for the same (network, physical_network) combination, which is problematic for us.
Line 4 is ok, as it's for another network. segmentation_id cannot be the same, but the VlanTypeDriver takes care.
Line 5 is ok even though segmentation_ids are duplicated to the above, because it's for another physical_network. The VlanTypeDriver knows that it can give them out again.
That's why we think, network_id should be part of the tuple. NULL values are actually allowed by UniqueContraints pretty much everywhere according to Stackoverflow [1] (and MySQL [2], PostgreSQL [3] specifically), so I don't think it's problematic for network-types not using a physical network, but we can test that it allows multiple ('networkid1', NULL, 'flat') tuples for a constraint on (network_id, physical_network, network_type).
Have a nice day,
Johannes
[1] https:/
[2] https:/
[3] https:/
[4] https:/