Open Stack

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> [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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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 
network work.

-- 

Thanks,

Matt Riedemann