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

2016-04-08 Thread Pavel Bondar
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

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

2016-04-05 Thread Carl Baldwin
I think the only thing standing in our way is this bug [1]. Ryan Tidwell and I are working on this. Carl [1] https://bugs.launchpad.net/neutron/+bug/1543094 On Mon, Apr 4, 2016 at 3:48 PM, John Belamaric wrote: > I was on vacation last week so I am just seeing this now. I agree that now > tha

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

2016-04-04 Thread John Belamaric
I was on vacation last week so I am just seeing this now. I agree that now that we are in Newton we should just remove the non-pluggable code and move forward with the migration. John __ OpenStack Development Mailing List (n

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

2016-03-30 Thread Carl Baldwin
On Wed, Mar 30, 2016 at 9:03 AM, Pavel Bondar wrote: > Kevin Benton commented on review page for current migration to pluggable > approach [1]: > > IMO this cannot be optional. It's going to be a nightmare to try to support > two IPAM systems that people may have switched between at various points

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

2016-03-30 Thread Neil Jerram
On 30/03/16 16:08, Pavel Bondar wrote: > We are now in early Newton, so it is good time to discuss plan for > pluggable ipam for this release cycle. > > Kevin Benton commented on review page for current migration to pluggable > approach [1]: >> >> IMO this cannot be optional. It's going to be a ni

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

2016-03-30 Thread Pavel Bondar
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

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

2016-02-16 Thread Carl Baldwin
On Mon, Feb 15, 2016 at 9:26 AM, Pavel Bondar wrote: > Your idea sounds workable to me. However I think a simpler way exists. I'll be happy to review your migration for Mitaka which should be totally out-of-band and leave both implementations intact. As for the details of the switch-over in Newt

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

2016-02-15 Thread Pavel Bondar
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

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

2016-02-12 Thread Carl Baldwin
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 may not care >>> about. >>> >> >> If we were to

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

2016-02-12 Thread Carl Baldwin
On Thu, Feb 11, 2016 at 10:04 AM, Armando M. wrote: > I believe we have more recovery options out a potentially fatal situation. > In fact the offline script can provide a dry-run option that can just > validate that the migration will succeed before it is even actually > performed; I think that t

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

2016-02-12 Thread Ihar Hrachyshka
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 implementation changes. That's not entirely true, is it? There are config variabl

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

2016-02-12 Thread Salvatore Orlando
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 implementation changes. >> > > That's not entirely true, is it? There are config variables to c

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

2016-02-11 Thread John Belamaric
On Feb 11, 2016, at 12:04 PM, Armando M. mailto:arma...@gmail.com>> wrote: On 11 February 2016 at 07:01, John Belamaric mailto:jbelama...@infoblox.com>> wrote: It is only internal implementation changes. That's not entirely true, is it? There are config variables to change and it opens u

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

2016-02-11 Thread Carl Baldwin
On Thu, Feb 11, 2016 at 10:04 AM, Armando M. wrote: > On 11 February 2016 at 07:01, John Belamaric > 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 ma

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

2016-02-11 Thread Carl Baldwin
On Thu, Feb 11, 2016 at 3:32 AM, Ihar Hrachyshka wrote: > Salvatore Orlando wrote: > >> The difference lies in the process in my opinion. >> If the switch is added into the migration path then we will tell operators >> when to switch. >> I was suggesting doing it manual because we just don't know

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

2016-02-11 Thread Carl Baldwin
On Thu, Feb 11, 2016 at 3:20 AM, Salvatore Orlando wrote: > The difference lies in the process in my opinion. > If the switch is added into the migration path then we will tell operators > when to switch. > I was suggesting doing it manual because we just don't know if every > operator is happy ab

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

2016-02-11 Thread Armando M.
On 11 February 2016 at 07:01, John Belamaric wrote: > > > --- > John Belamaric > (240) 383-6963 > > > On Feb 11, 2016, at 5:37 AM, Ihar Hrachyshka > wrote: > > > > What’s the user visible change in behaviour after the switch? If it’s > only internal implementation change, I don’t see why we want

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

2016-02-11 Thread Armando M.
On 10 February 2016 at 15:19, Carl Baldwin wrote: > On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote: > > Technically we can make this as sophisticated and seamless as we want, > but > > this is a one-off, once it's done the pain goes away, and we won't be > doing > > another migration like this

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

2016-02-11 Thread John Belamaric
--- John Belamaric (240) 383-6963 > On Feb 11, 2016, at 5:37 AM, Ihar Hrachyshka wrote: > > What’s the user visible change in behaviour after the switch? If it’s only > internal implementation change, I don’t see why we want to leave the choice > to operators. > It is only internal impleme

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

2016-02-11 Thread Ihar Hrachyshka
Salvatore Orlando wrote: The difference lies in the process in my opinion. If the switch is added into the migration path then we will tell operators when to switch. I was suggesting doing it manual because we just don't know if every operator is happy about doing the switch when upgrading

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

2016-02-11 Thread Salvatore Orlando
The difference lies in the process in my opinion. If the switch is added into the migration path then we will tell operators when to switch. I was suggesting doing it manual because we just don't know if every operator is happy about doing the switch when upgrading to Newton, but perhaps it is just

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

2016-02-10 Thread Carl Baldwin
On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote: > Technically we can make this as sophisticated and seamless as we want, but > this is a one-off, once it's done the pain goes away, and we won't be doing > another migration like this ever again. So I wouldn't over engineer it. Frankly, I was wor

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

2016-02-10 Thread Carl Baldwin
On Thu, Feb 4, 2016 at 8:12 PM, Armando M. wrote: > as for c) I think it's a little late to make pluggable ipam default in > Mitaka; I'd rather switch defaults early in the cycle (depending on the > entity of the config) and this one seems serious enough that I'd rather have > enough exercising in

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

2016-02-08 Thread Sean M. Collins
Salvatore Orlando wrote: > Agreed. Operators love to automate things, but they generally don't like > when components automatically do things they maybe do not expect to do (I > don't think we should assume all operators fully read release notes). So > the manual step is preferable, and not that pa

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

2016-02-08 Thread Pavel Bondar
On 06.02.2016 00:03, Salvatore Orlando wrote: > > > On 5 February 2016 at 17:58, Neil Jerram > wrote: > > On 05/02/16 16:31, Pavel Bondar wrote: > > On 05.02.2016 12:28, Salvatore Orlando wrote: > >> > >> > >> On 5 February 2016 at 04:12, Arma

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

2016-02-05 Thread Salvatore Orlando
On 5 February 2016 at 17:58, Neil Jerram wrote: > On 05/02/16 16:31, Pavel Bondar wrote: > > On 05.02.2016 12:28, Salvatore Orlando wrote: > >> > >> > >> On 5 February 2016 at 04:12, Armando M. >> > wrote: > >> > >> > >> > >> On 4 February 2016 at 08:22, John Belama

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

2016-02-05 Thread Neil Jerram
On 05/02/16 16:31, Pavel Bondar wrote: > On 05.02.2016 12:28, Salvatore Orlando wrote: >> >> >> On 5 February 2016 at 04:12, Armando M. > > wrote: >> >> >> >> On 4 February 2016 at 08:22, John Belamaric >> <jbelama...@infoblox.com> w

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

2016-02-05 Thread Pavel Bondar
On 05.02.2016 12:28, Salvatore Orlando wrote: > > > On 5 February 2016 at 04:12, Armando M. > wrote: > > > > On 4 February 2016 at 08:22, John Belamaric > mailto:jbelama...@infoblox.com>> wrote: > > > > On Feb 4, 2016, at 11:09 AM, Carl Baldwin > m

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

2016-02-05 Thread Salvatore Orlando
On 5 February 2016 at 04:12, Armando M. wrote: > > > On 4 February 2016 at 08:22, John Belamaric > wrote: > >> >> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin wrote: >> > >> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar >> wrote: >> >> I am trying to bring more attention to [1] to make final d

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

2016-02-04 Thread Armando M.
On 4 February 2016 at 08:22, John Belamaric wrote: > > > On Feb 4, 2016, at 11:09 AM, Carl Baldwin wrote: > > > > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar > wrote: > >> I am trying to bring more attention to [1] to make final decision on > >> approach to use. > >> There are a few point that

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

2016-02-04 Thread John Belamaric
> On Feb 4, 2016, at 11:09 AM, Carl Baldwin wrote: > > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar wrote: >> 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 s

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

2016-02-04 Thread Carl Baldwin
On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar wrote: > 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 M

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

2016-02-04 Thread Pavel Bondar
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_