On Sun, May 15, 2016 at 3:56 PM, Sean M. Collins <[email protected]> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
