Open Stack

On your first mail, the problem is going to be that much worse with
IPv6, where it's reasonable but unwise to try:

nova-manage floating-ip-create 2001:10::/64

Unused addresses need to be stored as ranges, not individually, making
floating-ip-create O(1).

On 30 October 2012 12:54, Christopher Yeoh <cyeoh at au1.ibm.com> wrote:
> On Mon, 29 Oct 2012 18:30:13 -0400
> Sean Dague <sdague at linux.vnet.ibm.com> wrote:
>> On 10/29/2012 05:57 PM, Christopher Yeoh wrote:
>>
>> It seems like for the delete case we could do something better than
>> nova.db.api.floating_ip_bulk_destroy(context, ips), perhaps a
>> nova.db.api.floating_ip_range_destroy(context, first, last) that
>> could be smarter with the filters so that it's not stacking up 256^3
>> filter statements.

And the problem with this is that the current DB stores IP addresses
textually and they can't be ordered in textual form.  You can play
games with INET_ATON and INET6_ATON in MySQL, but it's not portable
(PostgreSQL has a column type for addresses, instead; SQLite has
nothing) or you can do a conversion to sortable canonical sortable
form as in https://review.openstack.org/12557 - currently up for
review but causing disquiet because the binary column type is
unattractive.

> Good point - I'll have a look at that. I think something like
>
> nova.db.api.floating_ip_range_destroy(context, range)
>
> where range is a netaddr.IPNetwork (which is essentially what is
> passed to the API initially anyway) should be able to be implemented
> efficiently.
>
>> > Or should I attempt to simply reject any requests where there are
>> > too many ips being deleted/created at one time? (eg /24 as the
>> > biggest bulk request?)
>>
>> The create is always going to be expensive, but I don't think it
>> makes sense to arbitrarily limit the create / destroy sizes. If
>> that's what an admin actually needs, then that's what they need.
>
> I guess my concern is (if I'm understanding how things work
> properly) that an admin for one tenant could cause the api
> server to stop responding for quite a while for everyone.
>
> Regards,
>
> Chris
> --
> cyeoh at au.ibm.com
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev