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 auto-address
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] ht
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 07:01, John Belamaric
>>> wrote:
>>>
>>>
>>>
>>> It is only internal i
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 scenario that the operator m
On 06.02.2016 00:03, Salvatore Orlando wrote:
>
>
> On 5 February 2016 at 17:58, Neil Jerram <mailto:neil.jer...@metaswitch.com>> wrote:
>
> On 05/02/16 16:31, Pavel Bondar wrote:
> > On 05.02.2016 12:28, Salvatore Orlando wrote:
> >>
>
> On Feb 4, 2016, at 11:09 AM, Carl Baldwin
> mailto:c...@ecbaldwin.net>> wrote:
> >
> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar
> mailto:pbon...@infoblox.com>> wrote:
> >> I am trying to bring more attention to [1]
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 alembic_
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
ot run pluggable IPAM by default. I appreciate this would have some
> impact on unit tests as well, which should be run both for pluggable
> and "traditional" IPAM.
>
> Salvatore
>
> On 4 May 2015 at 20:11, Pavel Bondar <mailto:pbon...@
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 Ma
ady 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 Developm
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.20
ound good).
Anyone can checkout and debug patch set 50 (where issue 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/15
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 transactio
14 matches
Mail list logo
