Open Stack

Most of the discussions we have on this are workarounds.  We're trying
to improve the creation of 2^16 and up rows when we should probably
ask why we're creating them in the first place.

I think that a better fix to this is to move to storing a row
containing a range of unassigned floating IP addresses, rather than
one row per entry.  I can imagine someone expecting to add an IPv6 /64
in the future - fine, that is totally unnecessary, you'll never need
that many addresses, but there's no reason it shouldn't work, not from
the point of view of the caller.  A range reduces the add to O(1), but
makes assigning an IP from that range a little bit more complex.

[There's also a patch in Gerrit to improve the DB datatype for IP
addresses so that it's DB-comparable and orderable.  That would also
be useful for this area of the DB - not absolutely required, just a
nice-to-have - but none of the reviewers liked the implementation (the
stored datatype is not human readable) so it's unlikely to progress in
its current form.]

-- 
Ian.

On 16 November 2012 03:28, Vishvananda Ishaya <vishvananda at gmail.com> wrote:
> In the real world I think floating ips are created once when the cluster is deployed. Also in the real world you are running with osapi_workers=(something > 1) or running multiple api servers so blocking one of the processes/daemons isn't a huge deal if you need to run a big create.  Seems like not a huge issue to me.
>
> Vish
>
> On Nov 15, 2012, at 5:55 PM, Christopher Yeoh <cyeoh at au1.ibm.com> wrote:
>
>> Hi,
>>
>> Just wanting to bump this thread to see if we can
>> get some discussion going as the patch for adding the API
>> for this functionality is waiting on only this.
>>
>> Do any ops people think this is going to be an issue. Can I take
>> silence to mean that no one cares either way? :-)
>>
>> Chris
>>
>> On Mon, 12 Nov 2012 14:14:16 +1100
>> Michael Still <michael.still at canonical.com> wrote:
>>
>>> On 10/30/2012 08:57 AM, Christopher Yeoh wrote:
>>>
>>>> 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?)
>>>
>>> Sorry to re-awaken an old thread, but I was just chatting with Chris
>>> on IRC and I think this is an issue. A /16 with this code currently
>>> takes several minutes to create -- and its entirely possible that
>>> people will create something bigger.
>>>
>>> Do we think people will deploy this with a special API server just for
>>> admin requests, or just use the existing server?
>>>
>>> I suspect we should limit the size of creation requests to a /24 and
>>> have the client chunk. Its not too much more inefficient, and smooths
>>> the load on the API server.
>>>
>>> I'd like to see more discussion of this to be honest.
>>>
>>> Mikal
>>
>> --
>> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev