Personally I think that we shouldn't enforce the id. The id should be treated as a unique string and it is just an implementation detail that the nova-network backend uses an integer. We had a number of other resources in nova that were implemented on the backend as integers and later changed to using uuids.
Vish On Jul 10, 2013, at 3:12 AM, Jordan Pittier <[email protected]> wrote: > Hi, > Any ideas on this one ? Maybe I should forward this email to a more specific > ML ? > > > On Thu, Jul 4, 2013 at 4:36 PM, Jordan Pittier <[email protected]> wrote: > Hi guys, > > As you may know : > * with Quantum, secgroups are uniquely identified by UUID. > * with Nova-Net, secgroups are uniquely identified by numerical ID. > > At the moment Nova-api, before calling Nova-Net or Quantum,(see > nova/api/openstack/compute/contrib/security_group*) performs some calls to > validate_id(), defined in : > * nova/network/security_group/quantum_drive.py for Quantum > * nova/compute/api.py for Nova-Net > > Validate_id() raises an HTTPBadRequest in case the identifier is not an UUID > for Quantum or an ID for Nova-Net. > > > The first thing to notice is that : (1) It's Nova-API that performs > identifier validation and raises the exception. > > > This API mismatch breaks 4 Tempest tests (see > bugs.launchpad.net/tempest/+bug/1182384) and could be confusing to the user > as Sean Dague reported in this bug report. > > I see several approaches to deal with this : > 1) This API change can't be hidden, clients (and Tempest) must refer to > security groups by their specific identifier. Ie Clients must be aware of the > backing network implementation. (see review.openstack.org/#/c/29899/) > 2) Encapsulate all calls to validate_id() in a try/catch HTTPBadRequest and > raise a HTTPNotFound instead (exception translation) > 3) Don't do any kind of validation neither for Nova-Net not Quantum. Some > unit tests in test_quantum_security_groups.TestQuantumSecurityGroups must be > adapted/removed. (see review.openstack.org/#/c/35285/ patchset 2 and 4 for 2 > different approaches). Let Quantum and Nova-Net deal with malformed inputs. > > What do you think ? > Thanks a lot ! > Jordan > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
