[openstack-dev] [neutron] Update_port can not remove allocation from auto-addressed subnets

Hi, Currently using update_port workflow user can not remove ip addresses from auto-addressed subnets (SLAAC). It prevents me from implementing complete fix for [1]. Typically for removing ip address from port, 'fixed_ips' list is updated and ip address is cleaned up from it. But for

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

I believe during next week I will upload code for the one time switch to pluggable ipam using pure alembic migration. Thanks, Pavel On 05.04.2016 22:05, Carl Baldwin wrote: > I think the only thing standing in our way is this bug [1]. Ryan > Tidwell and I are working on this. > > Carl > > [1]

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 12.02.2016 15:01, Ihar Hrachyshka wrote: > Salvatore Orlando wrote: > >> On 11 February 2016 at 20:17, John Belamaric >> wrote: >> >>> On Feb 11, 2016, at 12:04 PM, Armando M. wrote: >>> >>> >>> >>> On 11 February 2016 at

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 13.02.2016 02:42, Carl Baldwin wrote: > On Fri, Feb 12, 2016 at 5:01 AM, Ihar Hrachyshka wrote: It is only internal implementation changes. That's not entirely true, is it? There are config variables to change and it opens up the possibility of a

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 06.02.2016 00:03, Salvatore Orlando wrote: > > > On 5 February 2016 at 17:58, Neil Jerram <neil.jer...@metaswitch.com > <mailto:neil.jer...@metaswitch.com>> wrote: > > On 05/02/16 16:31, Pavel Bondar wrote: > > On 05.02

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

@infoblox.com>> wrote: > > > > On Feb 4, 2016, at 11:09 AM, Carl Baldwin > <c...@ecbaldwin.net <mailto:c...@ecbaldwin.net>> wrote: > > > > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar > <pbon...@infoblox.

[openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

Hi, I am trying to bring more attention to [1] to make final decision on approach to use. There are a few point that are not 100% clear for me at this point. 1) Do we plan to switch all current clouds to pluggable ipam implementation in Mitaka? yes --> Then data migration can be done as

Re: [openstack-dev] [Neutron] IPAM drivers for BlueCat networks and Alcatel-Lucent VitalQIP

Hi Maruti, For now only Pluggable IPAM interface with reference IPAM driver were released, and I am working on implementing IPAM driver for Infoblox. But I am not aware about existense of IPAM drivers from BlueCat or Alcatel. If you want to investigate with pluggable IPAM more you can start with

Re: [openstack-dev] [Neutron][IPAM] Do we need migrate script for neutron IPAM now?

be run both for pluggable and traditional IPAM. Salvatore On 4 May 2015 at 20:11, Pavel Bondar pbon...@infoblox.com mailto:pbon...@infoblox.com wrote: Hi, During fixing failures in db_base_plugin_v2.py with new IPAM[1] I faced to check

Re: [openstack-dev] [Neutron] _get_subnet() in OpenContrail tests results in port deletion

wrote: I think the first workaround is the solution we're looking for as it better reflects the fact that opencontrail is a db-less plugin. I hope it will be the easier too, but you can never be too sure with neutron unit tests. Salvatore On 4 May 2015 at 12:56, Pavel Bondar pbon

Re: [openstack-dev] [Neutron] _get_subnet() in OpenContrail tests results in port deletion

Hi Kevin, Thanks for your answer, that is what I was looking for! I'll check with you in irc to decide which workaround is better: 1. Mocking NeutronDbSubnet fetch_subnet for opencontrail tests. 2. Using session.query() directly in NeutronDbSubnet fetch_subnet. - Pavel Bondar On 30.04.2015 22

[openstack-dev] [Neutron][IPAM] Do we need migrate script for neutron IPAM now?

quite big and hard for review. [1] https://review.openstack.org/#/c/153236 [2] http://logs.openstack.org/36/153236/54/check/check-grenade-dsvm-neutron/42ab4ac/logs/grenade.sh.txt.gz - Pavel Bondar __ OpenStack Development Mailing

[openstack-dev] [Neutron] _get_subnet() in OpenContrail tests results in port deletion

is observed) from review page[6]. Thank you in advance. - Pavel Bondar [1] http://logs.openstack.org/36/153236/50/check/gate-neutron-python27/dd83d43/testr_results.html.gz [2] https://review.openstack.org/#/c/153236/50/neutron/db/db_base_plugin_v2.py line 1578 / line 1857 [3] https

Re: [openstack-dev] [neutron][L3] IPAM alternate refactoring

Hi, I made some investigation on the topic[1] and see several issues on this way. 1. Plugin's create_port() is wrapped up in top level transaction for create floating ip case[2], so it becomes more complicated to do IPAM calls outside main db transaction. - for create floating ip case