[openstack-dev] [nova][neutron] Is it still valid/supported to create a network with a br-<uuid> id?
mriedem at linux.vnet.ibm.com
Mon May 16 16:21:29 UTC 2016
On 5/15/2016 7:42 PM, Jason Kölker wrote:
> 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> . That was added due to this bug from Folsom .
>>> 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 .
>> 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!
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Thanks for the detailed history lesson Jason. I'll move forward with
dropping that support in the microversion that lands with the get me a
More information about the OpenStack-dev