Open Stack

On 10/29/2012 05:57 PM, Christopher Yeoh wrote:
> Hi,
>
> I've been working on implementing the bulk creation/deletion of floating
> IPs. I've moved over the nova-manage implementation which has been a
> pretty straightforward process, but noticed that if you do something a
> with the original nova-manage command like:
>
> nova-manage delete 10.0.0.0/8
>
> it not so unexpectedly takes a very long time. Not so much a problem
> if you do it via nova-manage, but would I think be an issue for the API
> server.
>
> The underlying db calls floating_ip_bulk_create/destroy just
> take lists of IPs, but in the context of deletion/creation with the way
> IPs are stored in the db I'm not sure that can really be optimised
> anyway.
>
> So I think as it currently is implemented there is a denial of service
> issue. Any suggestions on what the right approach to this is?

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.

> Eg. if as I think its not possible to optimise large creation/deletes
> then is it ok if only admin users can access the API and that they
> should know better than to do this in the first place?
>
> 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.

	-Sean

-- 
Sean Dague
IBM Linux Technology Center
email: sdague at linux.vnet.ibm.com
alt-email: sldague at us.ibm.com