On 25 February 2015 at 16:52, Carl Baldwin wrote:
> jOn Mon, Feb 23, 2015 at 5:07 AM, Salvatore Orlando
> wrote:
> > Lazy-Stacker summary:
> > I am doing some work on Neutron IPAM code for IP Allocation, and I need
> to
> > found whether it's better to use db locking queries (SELECT ... FOR
> UP
On 2/25/15, 10:52 AM, "Carl Baldwin" wrote:
>
>Wondering if Kilo should just focus on creating the interface which
>will allow us to create multiple implementations and swap them out
>during the Liberty development cycle. Hopefully, this could include
>even something like your option 2 below.
>
On 25 February 2015 at 02:35, Robert Collins
wrote:
> On 24 February 2015 at 01:07, Salvatore Orlando
> wrote:
> > Lazy-Stacker summary:
> ...
> > In the medium term, there are a few things we might consider for
> Neutron's
> > "built-in IPAM".
> > 1) Move the allocation logic out of the driver,
On 25 February 2015 at 13:50, Eugene Nikanorov
wrote:
> Thanks for putting this all together, Salvatore.
>
> I just want to comment on this suggestion:
> > 1) Move the allocation logic out of the driver, thus making IPAM an
> independent service. The API workers will then communicate with the IPA
jOn Mon, Feb 23, 2015 at 5:07 AM, Salvatore Orlando wrote:
> Lazy-Stacker summary:
> I am doing some work on Neutron IPAM code for IP Allocation, and I need to
> found whether it's better to use db locking queries (SELECT ... FOR UPDATE)
> or some sort of non-blocking algorithm.
> Some measures su
Thanks Clint.
I think you are bringing an interesting and disruptive perspective into
this discussion.
Disruptive because one thing that has not been considered so far in this
thread is that perhaps we don't need at all to leverage multi-master
capabilities for write operations.
More comments inl
Excerpts from Salvatore Orlando's message of 2015-02-23 04:07:38 -0800:
> Lazy-Stacker summary:
> I am doing some work on Neutron IPAM code for IP Allocation, and I need to
> found whether it's better to use db locking queries (SELECT ... FOR UPDATE)
> or some sort of non-blocking algorithm.
> Some
Thanks for putting this all together, Salvatore.
I just want to comment on this suggestion:
> 1) Move the allocation logic out of the driver, thus making IPAM an
independent service. The API workers will then communicate with the IPAM
service through a message bus, where IP allocation requests wil
On 24 February 2015 at 01:07, Salvatore Orlando wrote:
> Lazy-Stacker summary:
...
> In the medium term, there are a few things we might consider for Neutron's
> "built-in IPAM".
> 1) Move the allocation logic out of the driver, thus making IPAM an
> independent service. The API workers will then
Lazy-Stacker summary:
I am doing some work on Neutron IPAM code for IP Allocation, and I need to
found whether it's better to use db locking queries (SELECT ... FOR UPDATE)
or some sort of non-blocking algorithm.
Some measures suggest that for this specific problem db-level locking is
more efficien
10 matches
Mail list logo
