I must have archived this on accident. Sorry to not respond earlier.
Comments inline...
On Feb 12, 2015 6:40 AM, Salvatore Orlando sorla...@nicira.com wrote:
I have updated the patch; albeit not complete yet it's kind of closer to
be an allocator decent enough to replace the built-in logic.
I
On Feb 13, 2015 5:54 AM, Salvatore Orlando sorla...@nicira.com wrote:
- Considering an alternative to availability ranges. Pre-generation of IP
entries is unpractical (think IPv6), so that's not an option.
Unfortunately, I have not yet explored in detail this route.
The availability range stuff
On Thu, Feb 12, 2015 at 6:36 AM, Salvatore Orlando sorla...@nicira.com wrote:
- I agree with Carl that the IPAM driver should not have explicit code paths
for autoaddress subnets, such as DHCPv6 stateless ones. In that case, the
consumer of the driver will generate the address and then to the
On 02/12/2015 02:36 PM, Salvatore Orlando wrote:
- I promised a non blocking algorithm for IP allocation. The one I was
developing was based on specifying the primary key on the ip_requests
table in a way that it would prevent two concurrent requests from
getting the same address, and would
On 13 February 2015 at 12:40, Rossella Sblendido rsblend...@suse.com
wrote:
On 02/12/2015 02:36 PM, Salvatore Orlando wrote:
- I promised a non blocking algorithm for IP allocation. The one I was
developing was based on specifying the primary key on the ip_requests
table in a way that it
Development Mailing List openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Update on DB IPAM driver
Hi,
I have updated the patch; albeit not complete yet it's kind of closer to
be an allocator decent enough to replace the built-in logic.
I will be unable to attend today's
Put it in this way, it also makes sense. But I think I need to see it
translated in code to figure it out properly. Anyway, this is something which
pertains the base classes rather than the reference driver.
I think from the perspective of the reference driver we should just raise if a
List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Update on DB IPAM driver
...
I think the auto-generated case should be a base class as you described in [1],
but each subclass would implement the specific
List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Update on DB IPAM driver
Hi,
I have updated the patch; albeit not complete yet it's kind of closer to be an
allocator decent enough to replace the built-in logic.
I will be unable
Hi,
I have updated the patch; albeit not complete yet it's kind of closer to be
an allocator decent enough to replace the built-in logic.
I will be unable to attend today's L3/IPAM meeting due to a conflict, so
here are some highlights from me on which your feedback is more than
welcome:
- I
10 matches
Mail list logo
