Open Stack

On Sun, May 15, 2016 at 3:56 PM, Sean M. Collins <sean at coreitpro.com> wrote:
> Matt Riedemann wrote:
>> The nova create-server API allows passing a network id that's prefixed with
>> br-<uuid> [1]. That was added due to this bug from Folsom [2].
>>
>> I'm wondering if that's still valid? Looking at the network.id data model in
>> Neutron it doesn't look like it would be [3].
>
> Wow. That bug is awful. Network IDs should be UUIDs and ONLY UUIDs.

I agree, I'm having flashbacks to the dark days right now

> Just because some vendor plugin decides that their going to break the
> Networking API contract and define their own ID scheme,
> doesn't mean that we should fix it to help them.

The networking API at the time (quantum 1.0/1.1, the 2.0 that we know
and loath today was added about 20 days prior, but not yet stable, or
deployed anywhere), used identifiers that were opaque strings. The
docs used uuid's as the identifiers for the examples, but the api
punted on validation to individual plugins.

> That commit shouldn't have been accepted into Nova,

Obviously I disagree, see below for the history.

> and I don't think
> that we should support anything but a UUID for a network id. Period.

Which is why this was fixed in the 2.0 api by checking the network
identifer for uuid-ness. This was the result of the fun of
shoe-horning every vendor's backend into quantum, without quantum
being the authority. Not to mention that the reason it was prefixed
with `br-` in the first place was established in the nova network api.
It exposed out the bridge that implemented the network in the nova
api, So the return from list networks on the nova side would list out
things like br-public, br-int, etc. This got carried over into the
quantum api when the project was founded.

I think we can all agree that this compat shim should be dropped now
that the v2.0 neutron api is merged and used (for quite sometime).

Happy Hacking!

7-11