On 5/15/2016 7:42 PM, Jason Kölker wrote:
On Sun, May 15, 2016 at 3:56 PM, Sean M. Collins <s...@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-requ...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
