Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-05-16 Thread Major Hayden 
On 05/15/2016 04:53 AM, Xav Paice wrote:
> Great stuff! - that's covered everything I've been looking at so far, except 
> that we're not wanting to run neutron-server (and therefore the octavia api) 
> on the same boxes as the Neutron L3 agent (where I understand we need to run 
> the worker).  This isn't the place for usage questions, I was wondering how 
> you deal with that separation or if it's not yet been worked into the branch?
> 
> I will assume that SSL certs haven't been dealt to yet?  I expect to be 
> throwing Barbican into the mix shortly to deal with that, maybe Anchor too.

I haven't done the work on that separation quite yet.  That could potentially 
be done using our existing affinity settings in OpenStack-Ansible, provided 
that Octavia is treated as a separate service.  My branch doesn't account for 
that.

There's some work underway to get barbican rolling with OpenStack-Ansible and 
that should make the certificate management part a bit easier.

> I'll run up a test env asap, seems that using your branch with some minor 
> updates might be just what we need.  Any updates will of course be shared :)

Great!

> Ugh - I really need to live in a country with a decent timezone.  I'm in 
> UTC+12 - will lurk around a bit and see who's online at the same time as I 
> am, and the whole project looks to be pretty friendly for newcomers.  I work 
> funny hours but 4am isn't when I'm at my best.

Either way, we usually have folks in the channel around the clock, so feel free 
to jump in and ask questions.

--
Major Hayden

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-05-15 Thread Xav Paice 
On 14 May 2016 at 00:27, Major Hayden  wrote:

>
> For what it's worth, I have a (somewhat dated) branch with Octavia support
> in Github[1].
>
>
>
Great stuff! - that's covered everything I've been looking at so far,
except that we're not wanting to run neutron-server (and therefore the
octavia api) on the same boxes as the Neutron L3 agent (where I understand
we need to run the worker).  This isn't the place for usage questions, I
was wondering how you deal with that separation or if it's not yet been
worked into the branch?

I will assume that SSL certs haven't been dealt to yet?  I expect to be
throwing Barbican into the mix shortly to deal with that, maybe Anchor too.


>
> We would definitely be happy to help with any questions you have while
> you're using OpenStack-Ansible.  It's always nice to have feedback from new
> users, especially those who are used to other deployment frameworks.  The
> OpenStack-Ansible contributors have done a lot to "smooth off" the rough
> edges of OpenStack deployments, but we find new things that surprise us
> from time to time. :)
>
>
I'll run up a test env asap, seems that using your branch with some minor
updates might be just what we need.  Any updates will of course be shared :)


> Feel free to join #openstack-ansible on Freenode or hang out with us
> during our IRC meetings on Thursday[2].
>

Ugh - I really need to live in a country with a decent timezone.  I'm in
UTC+12 - will lurk around a bit and see who's online at the same time as I
am, and the whole project looks to be pretty friendly for newcomers.  I
work funny hours but 4am isn't when I'm at my best.


>
> [1] https://github.com/major/openstack-ansible/tree/octavia
> [2] https://wiki.openstack.org/wiki/Meetings/openstack-ansible
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-05-13 Thread Major Hayden 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/12/2016 11:42 PM, Xav Paice wrote:
> Thanks for explaining that - I thought I was going mad.  You're right about 
> implementation challenges!

It's definitely a new way of doing things.  I'm trying to get used to this new 
service VM model (like Astara and Octavia use), but it's been difficult.

For what it's worth, I have a (somewhat dated) branch with Octavia support in 
Github[1].

> TBH, I'm writing something that would work at least in our environment and 
> trying to keep it as small and simple as possible so we can maintain it - 
> currently one of our dev team is adding a feature or two to make Octavia 
> match our business requirements, and I'm working on the deployment.  
> Openstack-ansible is quite a new approach for our deployment (we've done most 
> things via puppet till now) - what I was really after is some examples to 
> scab from, but if I manage to beat you to it, it might wind up the other way 
> round.  The Puppet deployment has been really good till recently but like 
> many, we're now unable to do 'big bang' upgrades and the lack of 
> orchestration in Puppet is a real limitation.
> 
> I'm happy to be involved with the implementation, but until we're using 
> openstack-ansible for our deployments my ability to test/run things would be 
> quite limited.
> 
> Maybe this is the push I need to knuckle down and migrate.

We would definitely be happy to help with any questions you have while you're 
using OpenStack-Ansible.  It's always nice to have feedback from new users, 
especially those who are used to other deployment frameworks.  The 
OpenStack-Ansible contributors have done a lot to "smooth off" the rough edges 
of OpenStack deployments, but we find new things that surprise us from time to 
time. :)

Feel free to join #openstack-ansible on Freenode or hang out with us during our 
IRC meetings on Thursday[2].

[1] https://github.com/major/openstack-ansible/tree/octavia
[2] https://wiki.openstack.org/wiki/Meetings/openstack-ansible

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXNcg2AAoJEHNwUeDBAR+xOeYP/iaIAxf23wh0qnpgehaOrHR9
+fJV+iHUweFo24k2twT2Bm6cwLbp5krb6ytP1RfTItznJqmBNxwkdgH7vZtIFW7x
nOCYPJnWbOaBB7C+fkiyfp4b7NJeJf2Otk9WOk7zCPp4q/dwKtz8bKWUvxtWRdvG
hlTM5UtQKKC+qpouOSB0nRofAtYAoYOUbn7PwRT0QO0e5cpQjX2Kcvm4NZZ4gVuV
RXHT8Z3CkhUY+sHOoFqx6yTj5XUpgjI2riaxK6LdDKxPV2fYJeDCJTWYBgwzBxsY
nKpf46YBuaSXSTMt6w6a92VpRPBUbnGcLptiynUpokKf2d7oJx4q51k7MY/zodLp
tACDMI8BADuMlmHVNypWjAyL06dtQF+KujboPQ6plz8cLY45cZ2pHLn8BHxviQdt
RNV2YcX7VRF/4wZPDRMTC66yuHYOTTYIaL+Gjgd8Yds4Ke2lFWN/Gl9ahMhcwT2l
NT4zxSwNLttmvAUaeADsmddHq+LtLEqGXjTNd6MDIEXtasvUtpNr+rT1QN/simpi
5QFAi/CHS6StSS+UIKh75PU3XWi3ssl+89tMzkE2u5KQzEXie624Oj+IGHMN1old
I8Szm4ZJU3kSU62H87hwgngKzpxuB6X9NjmXnvmudP6L+tJtTVswYBRXCylk7bvj
ywAQZ/FkpRn81EOIb5xb
=HuxP
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-05-12 Thread Xav Paice 
Thanks for explaining that - I thought I was going mad.  You're right about
implementation challenges!

TBH, I'm writing something that would work at least in our environment and
trying to keep it as small and simple as possible so we can maintain it -
currently one of our dev team is adding a feature or two to make Octavia
match our business requirements, and I'm working on the deployment.
Openstack-ansible is quite a new approach for our deployment (we've done
most things via puppet till now) - what I was really after is some examples
to scab from, but if I manage to beat you to it, it might wind up the other
way round.  The Puppet deployment has been really good till recently but
like many, we're now unable to do 'big bang' upgrades and the lack of
orchestration in Puppet is a real limitation.

I'm happy to be involved with the implementation, but until we're using
openstack-ansible for our deployments my ability to test/run things would
be quite limited.

Maybe this is the push I need to knuckle down and migrate.

On 12 May 2016 at 00:33, Major Hayden  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/10/2016 11:58 PM, Xav Paice wrote:
> > Sorry to dig up an ancient thread.
> >
> > I see the spec has been implemented, and in the os_neutron repo I see
> configs for the Haproxy driver for LOADBALANCERV2 - but not Octavia.  Am I
> missing something here?
>
> Hello Xav,
>
> No need to apologize -- I should have sent an update sooner. :)
>
> After a thorough review, we decided to go forth with LBaaSv2 via the agent
> since we needed something to quickly replace the now deprecated LBaaSv1
> API.  Octavia is still on the roadmap, but there are some implementation
> challenges that need more attention.
>
> I'm working to get more involved in some of the Octavia meetings and
> discussions so I can share the use cases of various OpenStack-Ansible
> operators.  Did you have some interest in helping with the implementation
> or are you eager to consume it once it's available?
>
> - --
> Major Hayden
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJXMyaMAAoJEHNwUeDBAR+xYwUP/iLfOuSOgW4TeOZ/pN0hkXuR
> H0L1suY6R+oGjDT+xuxox2uDcAADIWbHxBKosV/1jQHJRPoWfKhBhke4W2/MOsTV
> miqBrCKILLzJxdcXHrG54QHPb0FBqSLcmJIaFfysW1Rw3rH2btCSw8zoWNXipy39
> tYkDxh1z216gCIqNFSXSnpMgEj5D1LzAOZ1igBBOsYJYAwCvJp9XNcqAvN7FUg4C
> cvzSDztrb/r/CYtqqRYweD7vc70o/dz2Ej1wQn7ris0TrQHUiKU977NUMAiQmu+l
> 0YR/5FHV1VFMvZJGHv9J0gLWfq6sHhbqOOSLNuxtO9L99L25Knq72kOviipsYHWK
> IfIcP/s2KFIvX9mOrvMejXk2GKDSIb/vZ1LWTrS4Kg9i8rjVEroyHdO8/AHTpUK4
> bGbMcp3cqtTh1LHKu4NQh14SOvVwcR6hHVkRfcxO8l+YGghpexURjIOCGYGC+PI/
> Gk1t8bkW32x7+rZJHoiW/jBoWNR8l0ugFmS6VliJy9gufKEekCYZpIESPrnsHXjI
> 1NSOBv4QtpXXd+FJFNO2r9pRAzkj+CKrKQ9EJIr0wYbdiGEwic+CWOZwEw+Jsc5a
> DoQmS6iCVIZx5dxoO3Bes0F8k4Ov1mj2ZyYEN2JKArzArrDF/4NSDeSCNxYMGeRB
> 9NGm0sY4uHu6ZelxlFyS
> =sCy8
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-05-11 Thread Major Hayden 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/10/2016 11:58 PM, Xav Paice wrote:
> Sorry to dig up an ancient thread.
> 
> I see the spec has been implemented, and in the os_neutron repo I see configs 
> for the Haproxy driver for LOADBALANCERV2 - but not Octavia.  Am I missing 
> something here?

Hello Xav,

No need to apologize -- I should have sent an update sooner. :)

After a thorough review, we decided to go forth with LBaaSv2 via the agent 
since we needed something to quickly replace the now deprecated LBaaSv1 API.  
Octavia is still on the roadmap, but there are some implementation challenges 
that need more attention.

I'm working to get more involved in some of the Octavia meetings and 
discussions so I can share the use cases of various OpenStack-Ansible 
operators.  Did you have some interest in helping with the implementation or 
are you eager to consume it once it's available?

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXMyaMAAoJEHNwUeDBAR+xYwUP/iLfOuSOgW4TeOZ/pN0hkXuR
H0L1suY6R+oGjDT+xuxox2uDcAADIWbHxBKosV/1jQHJRPoWfKhBhke4W2/MOsTV
miqBrCKILLzJxdcXHrG54QHPb0FBqSLcmJIaFfysW1Rw3rH2btCSw8zoWNXipy39
tYkDxh1z216gCIqNFSXSnpMgEj5D1LzAOZ1igBBOsYJYAwCvJp9XNcqAvN7FUg4C
cvzSDztrb/r/CYtqqRYweD7vc70o/dz2Ej1wQn7ris0TrQHUiKU977NUMAiQmu+l
0YR/5FHV1VFMvZJGHv9J0gLWfq6sHhbqOOSLNuxtO9L99L25Knq72kOviipsYHWK
IfIcP/s2KFIvX9mOrvMejXk2GKDSIb/vZ1LWTrS4Kg9i8rjVEroyHdO8/AHTpUK4
bGbMcp3cqtTh1LHKu4NQh14SOvVwcR6hHVkRfcxO8l+YGghpexURjIOCGYGC+PI/
Gk1t8bkW32x7+rZJHoiW/jBoWNR8l0ugFmS6VliJy9gufKEekCYZpIESPrnsHXjI
1NSOBv4QtpXXd+FJFNO2r9pRAzkj+CKrKQ9EJIr0wYbdiGEwic+CWOZwEw+Jsc5a
DoQmS6iCVIZx5dxoO3Bes0F8k4Ov1mj2ZyYEN2JKArzArrDF/4NSDeSCNxYMGeRB
9NGm0sY4uHu6ZelxlFyS
=sCy8
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-05-10 Thread Xav Paice 
Sorry to dig up an ancient thread.

I see the spec has been implemented, and in the os_neutron repo I see
configs for the Haproxy driver for LOADBALANCERV2 - but not Octavia.  Am I
missing something here?

On 29 January 2016 at 10:03, Major Hayden  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 01/26/2016 01:48 PM, Kevin Carter wrote:
> > I personally think it'd be great to see this feature in OSA and I look
> forward to reviewing the spec.
>
> The first draft of the spec is in Gerrit:
>
>   https://review.openstack.org/#/c/273749/
>
> I appreciate any and all feedback! :)
>
> - --
> Major Hayden
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWqoIyAAoJEHNwUeDBAR+xjuEP/2TSZoziJFTbKCsu3LvfkXir
> qaC/J0XZTSZVfCFB1gjqdXAsSYQT0T8gxRvEAtWkjXQ9IjbNdn+JP1TS5KntZnLc
> PB5+Fg90zj00IG7RHTaeMirv9FHqRwVOwI8AQmLZRovD+t8QFIGMAFWzHYGHzRoP
> VigvNau1HEgMs525cA2cZwG0AaC2dmt5pnuWpX9sPtUklbGq4xlZgjOi5RZT3wjO
> yzG4LqimVpWnYhKB1WxE4VCwzFXSkvZ8QmNoAjj/yNJafyV0f/aQn9Zg0yZ3JGi6
> OZtpUrhS3NA+goog1BI5gObfo+cRGUUIkhSBzXgPOWAqXr19uMXhWWabAf5BhQFv
> 2I4l+mkwU7cVa5FMKIgOdT/CUd9Cs1hLKYVYePrEoFDRagZpKbcC7ozeWdSJb6ri
> GK766Wm9ypLshI75fZTsnzLRaJEGk25PpmggYG9afnS6lP1JMlZ78opiVGpu5ISb
> H+aWQDhZopG8wxBkQ21xpS3NaG/oIfVst0R6zrBpxTznRSPA/gnqSN8YHdHmr8M4
> z+zxXxeU7iSG1uc5Nu4rUrVydXId8Cm9lwH33VDqs0MOJmawpxu7HeK2fk2J4JQH
> Nqky4EQZu9lWVjwEyfrnFYNY/xxnolboQTCC/cvDokwp+NHMsZmnUdzbaPFhrayX
> 8u41SM4i4S+ffOURAvt+
> =jZxV
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-28 Thread Major Hayden 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/26/2016 01:48 PM, Kevin Carter wrote:
> I personally think it'd be great to see this feature in OSA and I look 
> forward to reviewing the spec.

The first draft of the spec is in Gerrit:

  https://review.openstack.org/#/c/273749/

I appreciate any and all feedback! :)

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWqoIyAAoJEHNwUeDBAR+xjuEP/2TSZoziJFTbKCsu3LvfkXir
qaC/J0XZTSZVfCFB1gjqdXAsSYQT0T8gxRvEAtWkjXQ9IjbNdn+JP1TS5KntZnLc
PB5+Fg90zj00IG7RHTaeMirv9FHqRwVOwI8AQmLZRovD+t8QFIGMAFWzHYGHzRoP
VigvNau1HEgMs525cA2cZwG0AaC2dmt5pnuWpX9sPtUklbGq4xlZgjOi5RZT3wjO
yzG4LqimVpWnYhKB1WxE4VCwzFXSkvZ8QmNoAjj/yNJafyV0f/aQn9Zg0yZ3JGi6
OZtpUrhS3NA+goog1BI5gObfo+cRGUUIkhSBzXgPOWAqXr19uMXhWWabAf5BhQFv
2I4l+mkwU7cVa5FMKIgOdT/CUd9Cs1hLKYVYePrEoFDRagZpKbcC7ozeWdSJb6ri
GK766Wm9ypLshI75fZTsnzLRaJEGk25PpmggYG9afnS6lP1JMlZ78opiVGpu5ISb
H+aWQDhZopG8wxBkQ21xpS3NaG/oIfVst0R6zrBpxTznRSPA/gnqSN8YHdHmr8M4
z+zxXxeU7iSG1uc5Nu4rUrVydXId8Cm9lwH33VDqs0MOJmawpxu7HeK2fk2J4JQH
Nqky4EQZu9lWVjwEyfrnFYNY/xxnolboQTCC/cvDokwp+NHMsZmnUdzbaPFhrayX
8u41SM4i4S+ffOURAvt+
=jZxV
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-27 Thread Jain, Vivek 
+1 on sharing/outlining migration script form v1 to v2. It will help lot of 
teams.

Thanks,
Vivek







On 1/26/16, 6:58 PM, "Kevin Carter" <kevin.car...@rackspace.com> wrote:

>I know that Neutron LBaaS V1 is still available in Liberty and functional, and 
>at this point I assume its in Mitaka (simply judging the code not the actual 
>functionality). From a production stand point I think its safe to say we can 
>keep supporting the V1 implementation for a while however we'll be stuck once 
>V1 is deprecated should there not be a proper migration path for old and new 
>LBs at that time. 
>
>I'd also echo the request from Kevin for a share on some of the migration 
>scripts that have been made such that we can all benefit from the prior art 
>that has already been created. @Eichberger If not possible to share the 
>"proprietary" scripts outright, maybe we could get an outline of the process / 
>whitepaper on what's been done so we can work on to getting the needful 
>migrations baked into Octavia proper? (/me speaking as someone with no 
>experience in Octavia nor the breath of work that I may be asking for however 
>I am interested in making things better for deployers, operators, developers)
>
>--
>
>Kevin Carter
>IRC: cloudnull
>
>
>
>From: Fox, Kevin M <kevin@pnnl.gov>
>Sent: Tuesday, January 26, 2016 5:38 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
>
>Thats very very unfortunate. :/ Lbaas team, (or any other team), please never 
>do this again. :/
>
>so does liberty/mitaka at least support using the old v1? it would be nice to 
>have a different flag day to upgrade the load balancers then the upgrade day 
>to get from kilo to release next...
>
>Any chance you can share your migration scripts? I'm guessing we're not the 
>only two clouds that need to migrate things.
>
>hmm Would it be possible to rename the tables to something else and tweak 
>a few lines of code so they could run in parallel? Or is there deeper 
>incompatibility then just the same table schema being interpreted differently?
>
>Thanks,
>Kevin
>
>From: Eichberger, German [german.eichber...@hpe.com]
>Sent: Tuesday, January 26, 2016 1:39 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
>
>Hi,
>
>As Brandon pointed out you can’t run V1 and V2 at the same time because they 
>share the same database tables and interpret columns differently. Hence, at 
>HPE we have some proprietary script which takes the V1 database tables and 
>migrates them to the V2 format. After that the v2 agent based driver will pick 
>it up and create those load balancers.
>
>To migrate agent based driver to Octavia we are thinking self migration since 
>people van use the same (ansible) scripts and point them at Octavia.
>
>Thanks,
>German
>
>
>
>On 1/26/16, 12:40 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:
>
>>I assumed they couldn't run on the same host, but would work on different 
>>hosts. maybe I was wrong?
>>
>>I've got a production cloud that's heavily using v1. Having a flag day where 
>>we upgrade all from v1 to v2 might be possible, but will be quite painful. If 
>>they can be made to co'exist, that would be substantially better.
>>
>>Thanks,
>>Kevin
>>
>>From: Brandon Logan [brandon.lo...@rackspace.com]
>>Sent: Tuesday, January 26, 2016 12:19 PM
>>To: openstack-dev@lists.openstack.org
>>Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
>>
>>Oh lbaas versioning was a big deal in the beginning.  Versioning an
>>advanced service is a whole other topic and exposed many "interesting"
>>issues with the neutron extension and service plugin framework.
>>
>>The reason v1 and v2 cannot be run together are mainly to get over an
>>issue we had with the 2 different agents which woudl have caused a much
>>larger refactor.  The v1 OR v2 requirement was basically a hack to get
>>around that.  Now that Octavia is the reference implementation and the
>>default, relaxing this restriction shouldn't cause any problems really.
>>Although, I don't want to 100% guarantee that because it's been a while
>>since I was in that world.
>>
>>If that were relaxed, the v2 agent and v1 agent could still be run at
>>the same time which is something to think about.  Come to think about
>>it, we might want to r

[openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Major Hayden 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey there,

After poking around a bit at LBaaS in OpenStack-Ansible, I discovered that 
LBaaS v2[1] was available in Liberty and Mitaka.  At first, I thought it 
involved switching agents from neutron-lbaas-agent to neutron-lbaasv2-agent, 
but things are a little bit more involved.

LBaaS v1 works by configuring HAProxy within agent containers.  However, LBaaS 
v2 creates virtual machines to hold load balancers and attaches those virtual 
machines to the appropriate subnet.  It offers some active/passive failover 
capabilities, but a single load balancer is the default.  One of the biggest 
benefits of v2 is that you can put multiple listeners on the same load 
balancer.  For example, you could host a website on ports 80 and 443 on the 
same VIP and floating IP address.

The provisioning would look like this for v2:

  * Create a load balancer
  * Create a listener
  * Create a pool
  * Create members in the pool

Many thanks to Brandon Logan (blogan) for sitting down with me this morning to 
go over it.  It looks like we'd need to do the following to get LBaaS v2 into 
OpenStack-Ansible:

  1) Build a new container to hold an Octavia venv

  2) Run four new daemons in that container:

* octavia-api
* octavia-worker
* octavia-housekeeping
* octavia-health-manager

  3) Ensure that neutron-lbaas-agent isn't running at the same time as the 
octavia stack

  4) Create a new RabbitMQ queue for octavia along with credentials

  5) Create a new MariaDB database for octavia along with credentials

At this moment, LBaaS v2 panels are planned for Horizon in Mitaka, but they're 
not available as of right now.  It seems like a spec would be necessary for 
this effort.

Are there users/deployers who would like to have this feature available?

[1] 
http://docs.openstack.org/developer/devstack/guides/devstack-with-lbaas-v2.html

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWp8usAAoJEHNwUeDBAR+xXk8P/37tkHZujAbbX3SY5X4dR2wX
cmR1DN+upBHJgVfrEKdFEBkGaS5ByZXnSvB0nGdJGYluL22DmNQRW2VxYDkqF+/W
h/0dprxEzscdYCt8cO/8LVftZ0krln7Wp7Yn8YUCLSm9yHPrrgUIUIJNm6r552Ts
BEJrdDaC+9R+vMstYFzdHKPegV53L25muXFCU7FM50WeGEXOgd72rMNf81VSQXUU
DBJzYyYvN8MZownOcvoh9aAH6a+ASwZmEMZpc7HGj2ltpc99LSfmuTT+t8Jzysr5
prCK6XBzzsedgYFWG2v1JZUOvTgjhbkeLIjPhYdnzfYp3b1sOz1qL9EXOcw/p4z7
xyHgns2HlpAMixTmqg+ZfaveGfqKAo6Pu+6z+BIT3+uqec7t1cQy3CQ7bBOX8GBe
PQyzU06jdT9x+/sarQGGfqMOfnX9XPEfUlfC7xa1KGUDdK7wf+yZdVf+D2Uh+vr/
K8Tohnswr6wDgVxB60Z+tptXkmSkV4jhPvXo9cPN2Gjed7/R1wb71XSb+OJ/3jxg
OdCVAz6mbCBxjWhrGkz7RR90NDZNy5CD3tqv22rVOuYZIFKw+IccCZ6KIfN8Fgne
XscCZPsZ2n/535PjAXDYqfHi+Qb7bAjjvj7Ast9bGNGrUiwNuoKa+L4HjFfopUqs
hXlq6F7n3pPmMCIgR76o
=KsIk
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Kevin Carter 
Seems like a sensible change however I'd love to see it written up as a spec. 
Also do we know if there are any scenario tests in tempest for octavia or would 
we need to develop them/something? 

As for adding Octavia as a new service within OpenStack Ansible this makes 
sense. Another approach may be to add octavia to the existing neutron-agent 
container which would making coordinating some of the services easier while 
ensuring the service deployment is simpler but that has isolation and 
segmentation drawback so i have no strong opinions on whats best. 

I personally think it'd be great to see this feature in OSA and I look forward 
to reviewing the spec.

--

Kevin Carter
IRC: cloudnull



From: Major Hayden <ma...@mhtx.net>
Sent: Tuesday, January 26, 2016 1:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey there,

After poking around a bit at LBaaS in OpenStack-Ansible, I discovered that 
LBaaS v2[1] was available in Liberty and Mitaka.  At first, I thought it 
involved switching agents from neutron-lbaas-agent to neutron-lbaasv2-agent, 
but things are a little bit more involved.

LBaaS v1 works by configuring HAProxy within agent containers.  However, LBaaS 
v2 creates virtual machines to hold load balancers and attaches those virtual 
machines to the appropriate subnet.  It offers some active/passive failover 
capabilities, but a single load balancer is the default.  One of the biggest 
benefits of v2 is that you can put multiple listeners on the same load 
balancer.  For example, you could host a website on ports 80 and 443 on the 
same VIP and floating IP address.

The provisioning would look like this for v2:

  * Create a load balancer
  * Create a listener
  * Create a pool
  * Create members in the pool

Many thanks to Brandon Logan (blogan) for sitting down with me this morning to 
go over it.  It looks like we'd need to do the following to get LBaaS v2 into 
OpenStack-Ansible:

  1) Build a new container to hold an Octavia venv

  2) Run four new daemons in that container:

* octavia-api
* octavia-worker
* octavia-housekeeping
* octavia-health-manager

  3) Ensure that neutron-lbaas-agent isn't running at the same time as the 
octavia stack

  4) Create a new RabbitMQ queue for octavia along with credentials

  5) Create a new MariaDB database for octavia along with credentials

At this moment, LBaaS v2 panels are planned for Horizon in Mitaka, but they're 
not available as of right now.  It seems like a spec would be necessary for 
this effort.

Are there users/deployers who would like to have this feature available?

[1] 
http://docs.openstack.org/developer/devstack/guides/devstack-with-lbaas-v2.html

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWp8usAAoJEHNwUeDBAR+xXk8P/37tkHZujAbbX3SY5X4dR2wX
cmR1DN+upBHJgVfrEKdFEBkGaS5ByZXnSvB0nGdJGYluL22DmNQRW2VxYDkqF+/W
h/0dprxEzscdYCt8cO/8LVftZ0krln7Wp7Yn8YUCLSm9yHPrrgUIUIJNm6r552Ts
BEJrdDaC+9R+vMstYFzdHKPegV53L25muXFCU7FM50WeGEXOgd72rMNf81VSQXUU
DBJzYyYvN8MZownOcvoh9aAH6a+ASwZmEMZpc7HGj2ltpc99LSfmuTT+t8Jzysr5
prCK6XBzzsedgYFWG2v1JZUOvTgjhbkeLIjPhYdnzfYp3b1sOz1qL9EXOcw/p4z7
xyHgns2HlpAMixTmqg+ZfaveGfqKAo6Pu+6z+BIT3+uqec7t1cQy3CQ7bBOX8GBe
PQyzU06jdT9x+/sarQGGfqMOfnX9XPEfUlfC7xa1KGUDdK7wf+yZdVf+D2Uh+vr/
K8Tohnswr6wDgVxB60Z+tptXkmSkV4jhPvXo9cPN2Gjed7/R1wb71XSb+OJ/3jxg
OdCVAz6mbCBxjWhrGkz7RR90NDZNy5CD3tqv22rVOuYZIFKw+IccCZ6KIfN8Fgne
XscCZPsZ2n/535PjAXDYqfHi+Qb7bAjjvj7Ast9bGNGrUiwNuoKa+L4HjFfopUqs
hXlq6F7n3pPmMCIgR76o
=KsIk
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Major Hayden 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/26/2016 01:48 PM, Kevin Carter wrote:
> Seems like a sensible change however I'd love to see it written up as a spec. 
> Also do we know if there are any scenario tests in tempest for octavia or 
> would we need to develop them/something? 
> 
> As for adding Octavia as a new service within OpenStack Ansible this makes 
> sense. Another approach may be to add octavia to the existing neutron-agent 
> container which would making coordinating some of the services easier while 
> ensuring the service deployment is simpler but that has isolation and 
> segmentation drawback so i have no strong opinions on whats best. 
> 
> I personally think it'd be great to see this feature in OSA and I look 
> forward to reviewing the spec.

Thanks, Kevin.  I'm wondering if it should be in the neutron-server instead of 
the agent container.  It doesn't need any special connections to isolated 
networks since it talks to neutron/nova to get that done.

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWp85iAAoJEHNwUeDBAR+x/BoP/RDR8dS4Z8/qf3xBPV6/Poff
ujj2ld7OgNDj+eZKsHNRnFZcoBxyHxIkNqFgUs12c0vZJ+q3zyFgDZRA8KdlFz+3
3GbDuHfBDUn56eGRvuIdXHYgVOLWWYHqnP7yUCE0Wvp2vuI3U5wZia0j6aD3Cizo
Tfl3Fh2S7lheOwVfslcc8w2GxFvqjdelK0ue2K9gAfY1y2wb2HpjfHnKiKcQ0fw6
lVZ3MacULsq9o56xJBsS87XooZrnt803F/WVHy6hA/MHUQHw7/3z2veF8zmthqsP
YZCPx85d/Sr8pFcxMo7MaZ6D0fB4kskkEz6Qaa/SzpPq28Mo7LOTFXLRDUPTOuDD
S5GLVxqmiWcdE4CnLXj+umOr4wXEKiEBlSVI+6BCSnx4VAANNQlPgQL83vIlpBl1
Ym29KpQB+T4YRKki2SVd0MKbucnqNE+/ZG19fju8TohZR3zigJFEpG4uY878ScZ0
8+4s/RAN272Fn2JQc99MsMhcvbKOWyY13n27dR4mIYkGeMeODXCYG9zmJ30wtJnX
x1MoKAddC9l49jiWj/jvtl+nmpHMsfAObwZ3LmY5mQ4w5/2wnuxXcGpDkps+aNUN
JzN3uBUiGseXleV6zZYhpLJwMmXwFM6trhftx6iAPwpIJg8tsYhE/50joj5m+VS9
WJEtVxSVWFMiJUOFOU4t
=mXI/
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Brandon Logan 
Hi Kevin,

On Tue, 2016-01-26 at 19:48 +, Kevin Carter wrote:
> Seems like a sensible change however I'd love to see it written up as a spec. 
> Also do we know if there are any scenario tests in tempest for octavia or 
> would we need to develop them/something?

There aren't any tempest tests specific to Octavia right now but they
are being worked on.  We've been using the tempest tests written for
neutron-lbaas for this and its been okay but it leaves many gaps because
neutron-lbaas tests should not be aware of how a driver implements what
it does.  Tempest tests just for octavia would fill in all those gaps
and make the product much more stable.

There is an effort going on to create the tempest tests right now
though.  I hope we can get some in by M3 but its uncertain right now.

>  
> 
> As for adding Octavia as a new service within OpenStack Ansible this makes 
> sense. Another approach may be to add octavia to the existing neutron-agent 
> container which would making coordinating some of the services easier while 
> ensuring the service deployment is simpler but that has isolation and 
> segmentation drawback so i have no strong opinions on whats best. 
> 
> I personally think it'd be great to see this feature in OSA and I look 
> forward to reviewing the spec.
> 
> --
> 
> Kevin Carter
> IRC: cloudnull
> 
> 
> 
> From: Major Hayden <ma...@mhtx.net>
> Sent: Tuesday, January 26, 2016 1:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
> 
> Hey there,
> 
> After poking around a bit at LBaaS in OpenStack-Ansible, I discovered that 
> LBaaS v2[1] was available in Liberty and Mitaka.  At first, I thought it 
> involved switching agents from neutron-lbaas-agent to neutron-lbaasv2-agent, 
> but things are a little bit more involved.
> 
> LBaaS v1 works by configuring HAProxy within agent containers.  However, 
> LBaaS v2 creates virtual machines to hold load balancers and attaches those 
> virtual machines to the appropriate subnet.  It offers some active/passive 
> failover capabilities, but a single load balancer is the default.  One of the 
> biggest benefits of v2 is that you can put multiple listeners on the same 
> load balancer.  For example, you could host a website on ports 80 and 443 on 
> the same VIP and floating IP address.
> 
> The provisioning would look like this for v2:
> 
>   * Create a load balancer
>   * Create a listener
>   * Create a pool
>   * Create members in the pool
> 
> Many thanks to Brandon Logan (blogan) for sitting down with me this morning 
> to go over it.  It looks like we'd need to do the following to get LBaaS v2 
> into OpenStack-Ansible:
> 
>   1) Build a new container to hold an Octavia venv
> 
>   2) Run four new daemons in that container:
> 
> * octavia-api
> * octavia-worker
> * octavia-housekeeping
> * octavia-health-manager
> 
>   3) Ensure that neutron-lbaas-agent isn't running at the same time as the 
> octavia stack
> 
>   4) Create a new RabbitMQ queue for octavia along with credentials
> 
>   5) Create a new MariaDB database for octavia along with credentials
> 
> At this moment, LBaaS v2 panels are planned for Horizon in Mitaka, but 
> they're not available as of right now.  It seems like a spec would be 
> necessary for this effort.
> 
> Are there users/deployers who would like to have this feature available?
> 
> [1] 
> http://docs.openstack.org/developer/devstack/guides/devstack-with-lbaas-v2.html
> 
> --
> Major Hayden
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thanks,
Brandon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Fox, Kevin M 
I believe lbaas v1 and v2 are different then every other openstack api version 
in that while you can run v1 and v2 at the same time but they are completely 
different systems that just share a name. A lb created in v1 doesn't show up in 
v2 or vis a versa. But being able to enable both at once gives users a 
migration path. If you don't do this, all their lb's will just disappear when 
going to octavia. :/

Thanks,
Kevin

From: Major Hayden [ma...@mhtx.net]
Sent: Tuesday, January 26, 2016 11:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey there,

After poking around a bit at LBaaS in OpenStack-Ansible, I discovered that 
LBaaS v2[1] was available in Liberty and Mitaka.  At first, I thought it 
involved switching agents from neutron-lbaas-agent to neutron-lbaasv2-agent, 
but things are a little bit more involved.

LBaaS v1 works by configuring HAProxy within agent containers.  However, LBaaS 
v2 creates virtual machines to hold load balancers and attaches those virtual 
machines to the appropriate subnet.  It offers some active/passive failover 
capabilities, but a single load balancer is the default.  One of the biggest 
benefits of v2 is that you can put multiple listeners on the same load 
balancer.  For example, you could host a website on ports 80 and 443 on the 
same VIP and floating IP address.

The provisioning would look like this for v2:

  * Create a load balancer
  * Create a listener
  * Create a pool
  * Create members in the pool

Many thanks to Brandon Logan (blogan) for sitting down with me this morning to 
go over it.  It looks like we'd need to do the following to get LBaaS v2 into 
OpenStack-Ansible:

  1) Build a new container to hold an Octavia venv

  2) Run four new daemons in that container:

* octavia-api
* octavia-worker
* octavia-housekeeping
* octavia-health-manager

  3) Ensure that neutron-lbaas-agent isn't running at the same time as the 
octavia stack

  4) Create a new RabbitMQ queue for octavia along with credentials

  5) Create a new MariaDB database for octavia along with credentials

At this moment, LBaaS v2 panels are planned for Horizon in Mitaka, but they're 
not available as of right now.  It seems like a spec would be necessary for 
this effort.

Are there users/deployers who would like to have this feature available?

[1] 
http://docs.openstack.org/developer/devstack/guides/devstack-with-lbaas-v2.html

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWp8usAAoJEHNwUeDBAR+xXk8P/37tkHZujAbbX3SY5X4dR2wX
cmR1DN+upBHJgVfrEKdFEBkGaS5ByZXnSvB0nGdJGYluL22DmNQRW2VxYDkqF+/W
h/0dprxEzscdYCt8cO/8LVftZ0krln7Wp7Yn8YUCLSm9yHPrrgUIUIJNm6r552Ts
BEJrdDaC+9R+vMstYFzdHKPegV53L25muXFCU7FM50WeGEXOgd72rMNf81VSQXUU
DBJzYyYvN8MZownOcvoh9aAH6a+ASwZmEMZpc7HGj2ltpc99LSfmuTT+t8Jzysr5
prCK6XBzzsedgYFWG2v1JZUOvTgjhbkeLIjPhYdnzfYp3b1sOz1qL9EXOcw/p4z7
xyHgns2HlpAMixTmqg+ZfaveGfqKAo6Pu+6z+BIT3+uqec7t1cQy3CQ7bBOX8GBe
PQyzU06jdT9x+/sarQGGfqMOfnX9XPEfUlfC7xa1KGUDdK7wf+yZdVf+D2Uh+vr/
K8Tohnswr6wDgVxB60Z+tptXkmSkV4jhPvXo9cPN2Gjed7/R1wb71XSb+OJ/3jxg
OdCVAz6mbCBxjWhrGkz7RR90NDZNy5CD3tqv22rVOuYZIFKw+IccCZ6KIfN8Fgne
XscCZPsZ2n/535PjAXDYqfHi+Qb7bAjjvj7Ast9bGNGrUiwNuoKa+L4HjFfopUqs
hXlq6F7n3pPmMCIgR76o
=KsIk
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Major Hayden 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/26/2016 02:01 PM, Fox, Kevin M wrote:
> I believe lbaas v1 and v2 are different then every other openstack api 
> version in that while you can run v1 and v2 at the same time but they are 
> completely different systems that just share a name. A lb created in v1 
> doesn't show up in v2 or vis a versa. But being able to enable both at once 
> gives users a migration path. If you don't do this, all their lb's will just 
> disappear when going to octavia. :/

I tend to agree, but I'm hearing that it's not possible to run both versions 
concurrently.  Brandon might be able to share a little more about the reasons 
why.

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWp9HwAAoJEHNwUeDBAR+x1vEP/A7b+3u42wo9Xf+YUxk83gzr
gWghI6Q/hSy/cF7lqzOUAPzm+vu/ThpLOx7x5AEbxMYIDXgNZVmU0wExhmRodH+r
gyohCixhsndpLpz/u5BfN2HAX9xz3RrdmxH8mSJ7PbzWDQu23+0Mi1coIa2HeEYV
RQeObSnSQCr7rYBW7u2yqFPEj1hn39wzoI3uTFMlswH3XO+VVHw/vWsYn8xBV9nd
MPamrteZzIS4ztNx5yaj11V7VWNWnKQdb1Zlp5Ma4GiiqrkKISkzpxeRAhoxl8K1
XrcFKsWUcIlMGuUHOlhHGlNnnBJhQlmyq0jiG0M1dZTBU9WNQnRl0R9I4gPmOoyF
zlOvJyJ+QnPEVBQmcv4XLkkYZdMupoSASNQFfWfYAciBO2/WFPRQ1bGa3CBLZYav
YPEIWhIrIyh5AHzzel58Xs9i2wmw+B465FmIr6M6o1aGhhk9GrJgQ7qF3H5fCe+b
bRJOv5Ixfb3BAxaLwZT3qmyciWeNaDHilk3Z7b96w/O8L4hNEZKxZegu5BiGDq0G
MBaSXi1TfVEXGYY/zW391uQWlYkauHIZTQXsFF5wf2PE8ezG4dltdUwsPbMUkMMB
XZ3WuQW8Ly5jUlEa8153a6l9oveE27IhiSFDbnFQkmGkiW74qgcUNEvtj19thCBf
BfEd4xbszDatbhi7Y1TO
=ZSVT
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Brandon Logan 
Oh lbaas versioning was a big deal in the beginning.  Versioning an
advanced service is a whole other topic and exposed many "interesting"
issues with the neutron extension and service plugin framework.

The reason v1 and v2 cannot be run together are mainly to get over an
issue we had with the 2 different agents which woudl have caused a much
larger refactor.  The v1 OR v2 requirement was basically a hack to get
around that.  Now that Octavia is the reference implementation and the
default, relaxing this restriction shouldn't cause any problems really.
Although, I don't want to 100% guarantee that because it's been a while
since I was in that world.

If that were relaxed, the v2 agent and v1 agent could still be run at
the same time which is something to think about.  Come to think about
it, we might want to revisit whether the v2 and v1 agent running
together is something that can be easily fixed because many things have
improved since then AND my knowledge has obviously improved a lot since
that time.

Glad yall brought this up.

Thanks,
Brandon


On Tue, 2016-01-26 at 14:07 -0600, Major Hayden wrote:
> On 01/26/2016 02:01 PM, Fox, Kevin M wrote:
> > I believe lbaas v1 and v2 are different then every other openstack api 
> > version in that while you can run v1 and v2 at the same time but they are 
> > completely different systems that just share a name. A lb created in v1 
> > doesn't show up in v2 or vis a versa. But being able to enable both at once 
> > gives users a migration path. If you don't do this, all their lb's will 
> > just disappear when going to octavia. :/
> 
> I tend to agree, but I'm hearing that it's not possible to run both versions 
> concurrently.  Brandon might be able to share a little more about the reasons 
> why.
> 
> --
> Major Hayden
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Fox, Kevin M 
Really? This is going to cause me a major headache if true. Brandon, do you 
have any details?

Thanks,
Kevin

From: Major Hayden [ma...@mhtx.net]
Sent: Tuesday, January 26, 2016 12:07 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/26/2016 02:01 PM, Fox, Kevin M wrote:
> I believe lbaas v1 and v2 are different then every other openstack api 
> version in that while you can run v1 and v2 at the same time but they are 
> completely different systems that just share a name. A lb created in v1 
> doesn't show up in v2 or vis a versa. But being able to enable both at once 
> gives users a migration path. If you don't do this, all their lb's will just 
> disappear when going to octavia. :/

I tend to agree, but I'm hearing that it's not possible to run both versions 
concurrently.  Brandon might be able to share a little more about the reasons 
why.

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWp9HwAAoJEHNwUeDBAR+x1vEP/A7b+3u42wo9Xf+YUxk83gzr
gWghI6Q/hSy/cF7lqzOUAPzm+vu/ThpLOx7x5AEbxMYIDXgNZVmU0wExhmRodH+r
gyohCixhsndpLpz/u5BfN2HAX9xz3RrdmxH8mSJ7PbzWDQu23+0Mi1coIa2HeEYV
RQeObSnSQCr7rYBW7u2yqFPEj1hn39wzoI3uTFMlswH3XO+VVHw/vWsYn8xBV9nd
MPamrteZzIS4ztNx5yaj11V7VWNWnKQdb1Zlp5Ma4GiiqrkKISkzpxeRAhoxl8K1
XrcFKsWUcIlMGuUHOlhHGlNnnBJhQlmyq0jiG0M1dZTBU9WNQnRl0R9I4gPmOoyF
zlOvJyJ+QnPEVBQmcv4XLkkYZdMupoSASNQFfWfYAciBO2/WFPRQ1bGa3CBLZYav
YPEIWhIrIyh5AHzzel58Xs9i2wmw+B465FmIr6M6o1aGhhk9GrJgQ7qF3H5fCe+b
bRJOv5Ixfb3BAxaLwZT3qmyciWeNaDHilk3Z7b96w/O8L4hNEZKxZegu5BiGDq0G
MBaSXi1TfVEXGYY/zW391uQWlYkauHIZTQXsFF5wf2PE8ezG4dltdUwsPbMUkMMB
XZ3WuQW8Ly5jUlEa8153a6l9oveE27IhiSFDbnFQkmGkiW74qgcUNEvtj19thCBf
BfEd4xbszDatbhi7Y1TO
=ZSVT
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Fox, Kevin M 
I assumed they couldn't run on the same host, but would work on different 
hosts. maybe I was wrong?

I've got a production cloud that's heavily using v1. Having a flag day where we 
upgrade all from v1 to v2 might be possible, but will be quite painful. If they 
can be made to co'exist, that would be substantially better.

Thanks,
Kevin

From: Brandon Logan [brandon.lo...@rackspace.com]
Sent: Tuesday, January 26, 2016 12:19 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

Oh lbaas versioning was a big deal in the beginning.  Versioning an
advanced service is a whole other topic and exposed many "interesting"
issues with the neutron extension and service plugin framework.

The reason v1 and v2 cannot be run together are mainly to get over an
issue we had with the 2 different agents which woudl have caused a much
larger refactor.  The v1 OR v2 requirement was basically a hack to get
around that.  Now that Octavia is the reference implementation and the
default, relaxing this restriction shouldn't cause any problems really.
Although, I don't want to 100% guarantee that because it's been a while
since I was in that world.

If that were relaxed, the v2 agent and v1 agent could still be run at
the same time which is something to think about.  Come to think about
it, we might want to revisit whether the v2 and v1 agent running
together is something that can be easily fixed because many things have
improved since then AND my knowledge has obviously improved a lot since
that time.

Glad yall brought this up.

Thanks,
Brandon


On Tue, 2016-01-26 at 14:07 -0600, Major Hayden wrote:
> On 01/26/2016 02:01 PM, Fox, Kevin M wrote:
> > I believe lbaas v1 and v2 are different then every other openstack api 
> > version in that while you can run v1 and v2 at the same time but they are 
> > completely different systems that just share a name. A lb created in v1 
> > doesn't show up in v2 or vis a versa. But being able to enable both at once 
> > gives users a migration path. If you don't do this, all their lb's will 
> > just disappear when going to octavia. :/
>
> I tend to agree, but I'm hearing that it's not possible to run both versions 
> concurrently.  Brandon might be able to share a little more about the reasons 
> why.
>
> --
> Major Hayden
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Eichberger, German 
Hi,

As Brandon pointed out you can’t run V1 and V2 at the same time because they 
share the same database tables and interpret columns differently. Hence, at HPE 
we have some proprietary script which takes the V1 database tables and migrates 
them to the V2 format. After that the v2 agent based driver will pick it up and 
create those load balancers.

To migrate agent based driver to Octavia we are thinking self migration since 
people van use the same (ansible) scripts and point them at Octavia.

Thanks,
German



On 1/26/16, 12:40 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>I assumed they couldn't run on the same host, but would work on different 
>hosts. maybe I was wrong?
>
>I've got a production cloud that's heavily using v1. Having a flag day where 
>we upgrade all from v1 to v2 might be possible, but will be quite painful. If 
>they can be made to co'exist, that would be substantially better.
>
>Thanks,
>Kevin
>
>From: Brandon Logan [brandon.lo...@rackspace.com]
>Sent: Tuesday, January 26, 2016 12:19 PM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
>
>Oh lbaas versioning was a big deal in the beginning.  Versioning an
>advanced service is a whole other topic and exposed many "interesting"
>issues with the neutron extension and service plugin framework.
>
>The reason v1 and v2 cannot be run together are mainly to get over an
>issue we had with the 2 different agents which woudl have caused a much
>larger refactor.  The v1 OR v2 requirement was basically a hack to get
>around that.  Now that Octavia is the reference implementation and the
>default, relaxing this restriction shouldn't cause any problems really.
>Although, I don't want to 100% guarantee that because it's been a while
>since I was in that world.
>
>If that were relaxed, the v2 agent and v1 agent could still be run at
>the same time which is something to think about.  Come to think about
>it, we might want to revisit whether the v2 and v1 agent running
>together is something that can be easily fixed because many things have
>improved since then AND my knowledge has obviously improved a lot since
>that time.
>
>Glad yall brought this up.
>
>Thanks,
>Brandon
>
>
>On Tue, 2016-01-26 at 14:07 -0600, Major Hayden wrote:
>> On 01/26/2016 02:01 PM, Fox, Kevin M wrote:
>> > I believe lbaas v1 and v2 are different then every other openstack api 
>> > version in that while you can run v1 and v2 at the same time but they are 
>> > completely different systems that just share a name. A lb created in v1 
>> > doesn't show up in v2 or vis a versa. But being able to enable both at 
>> > once gives users a migration path. If you don't do this, all their lb's 
>> > will just disappear when going to octavia. :/
>>
>> I tend to agree, but I'm hearing that it's not possible to run both versions 
>> concurrently.  Brandon might be able to share a little more about the 
>> reasons why.
>>
>> --
>> Major Hayden
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Fox, Kevin M 
Thats very very unfortunate. :/ Lbaas team, (or any other team), please never 
do this again. :/

so does liberty/mitaka at least support using the old v1? it would be nice to 
have a different flag day to upgrade the load balancers then the upgrade day to 
get from kilo to release next... 

Any chance you can share your migration scripts? I'm guessing we're not the 
only two clouds that need to migrate things.

hmm Would it be possible to rename the tables to something else and tweak a 
few lines of code so they could run in parallel? Or is there deeper 
incompatibility then just the same table schema being interpreted differently?

Thanks,
Kevin

From: Eichberger, German [german.eichber...@hpe.com]
Sent: Tuesday, January 26, 2016 1:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

Hi,

As Brandon pointed out you can’t run V1 and V2 at the same time because they 
share the same database tables and interpret columns differently. Hence, at HPE 
we have some proprietary script which takes the V1 database tables and migrates 
them to the V2 format. After that the v2 agent based driver will pick it up and 
create those load balancers.

To migrate agent based driver to Octavia we are thinking self migration since 
people van use the same (ansible) scripts and point them at Octavia.

Thanks,
German



On 1/26/16, 12:40 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>I assumed they couldn't run on the same host, but would work on different 
>hosts. maybe I was wrong?
>
>I've got a production cloud that's heavily using v1. Having a flag day where 
>we upgrade all from v1 to v2 might be possible, but will be quite painful. If 
>they can be made to co'exist, that would be substantially better.
>
>Thanks,
>Kevin
>
>From: Brandon Logan [brandon.lo...@rackspace.com]
>Sent: Tuesday, January 26, 2016 12:19 PM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
>
>Oh lbaas versioning was a big deal in the beginning.  Versioning an
>advanced service is a whole other topic and exposed many "interesting"
>issues with the neutron extension and service plugin framework.
>
>The reason v1 and v2 cannot be run together are mainly to get over an
>issue we had with the 2 different agents which woudl have caused a much
>larger refactor.  The v1 OR v2 requirement was basically a hack to get
>around that.  Now that Octavia is the reference implementation and the
>default, relaxing this restriction shouldn't cause any problems really.
>Although, I don't want to 100% guarantee that because it's been a while
>since I was in that world.
>
>If that were relaxed, the v2 agent and v1 agent could still be run at
>the same time which is something to think about.  Come to think about
>it, we might want to revisit whether the v2 and v1 agent running
>together is something that can be easily fixed because many things have
>improved since then AND my knowledge has obviously improved a lot since
>that time.
>
>Glad yall brought this up.
>
>Thanks,
>Brandon
>
>
>On Tue, 2016-01-26 at 14:07 -0600, Major Hayden wrote:
>> On 01/26/2016 02:01 PM, Fox, Kevin M wrote:
>> > I believe lbaas v1 and v2 are different then every other openstack api 
>> > version in that while you can run v1 and v2 at the same time but they are 
>> > completely different systems that just share a name. A lb created in v1 
>> > doesn't show up in v2 or vis a versa. But being able to enable both at 
>> > once gives users a migration path. If you don't do this, all their lb's 
>> > will just disappear when going to octavia. :/
>>
>> I tend to agree, but I'm hearing that it's not possible to run both versions 
>> concurrently.  Brandon might be able to share a little more about the 
>> reasons why.
>>
>> --
>> Major Hayden
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubsc

Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

2016-01-26 Thread Kevin Carter 
I know that Neutron LBaaS V1 is still available in Liberty and functional, and 
at this point I assume its in Mitaka (simply judging the code not the actual 
functionality). From a production stand point I think its safe to say we can 
keep supporting the V1 implementation for a while however we'll be stuck once 
V1 is deprecated should there not be a proper migration path for old and new 
LBs at that time. 

I'd also echo the request from Kevin for a share on some of the migration 
scripts that have been made such that we can all benefit from the prior art 
that has already been created. @Eichberger If not possible to share the 
"proprietary" scripts outright, maybe we could get an outline of the process / 
whitepaper on what's been done so we can work on to getting the needful 
migrations baked into Octavia proper? (/me speaking as someone with no 
experience in Octavia nor the breath of work that I may be asking for however I 
am interested in making things better for deployers, operators, developers)

--

Kevin Carter
IRC: cloudnull



From: Fox, Kevin M <kevin@pnnl.gov>
Sent: Tuesday, January 26, 2016 5:38 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

Thats very very unfortunate. :/ Lbaas team, (or any other team), please never 
do this again. :/

so does liberty/mitaka at least support using the old v1? it would be nice to 
have a different flag day to upgrade the load balancers then the upgrade day to 
get from kilo to release next...

Any chance you can share your migration scripts? I'm guessing we're not the 
only two clouds that need to migrate things.

hmm Would it be possible to rename the tables to something else and tweak a 
few lines of code so they could run in parallel? Or is there deeper 
incompatibility then just the same table schema being interpreted differently?

Thanks,
Kevin

From: Eichberger, German [german.eichber...@hpe.com]
Sent: Tuesday, January 26, 2016 1:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support

Hi,

As Brandon pointed out you can’t run V1 and V2 at the same time because they 
share the same database tables and interpret columns differently. Hence, at HPE 
we have some proprietary script which takes the V1 database tables and migrates 
them to the V2 format. After that the v2 agent based driver will pick it up and 
create those load balancers.

To migrate agent based driver to Octavia we are thinking self migration since 
people van use the same (ansible) scripts and point them at Octavia.

Thanks,
German



On 1/26/16, 12:40 PM, "Fox, Kevin M" <kevin@pnnl.gov> wrote:

>I assumed they couldn't run on the same host, but would work on different 
>hosts. maybe I was wrong?
>
>I've got a production cloud that's heavily using v1. Having a flag day where 
>we upgrade all from v1 to v2 might be possible, but will be quite painful. If 
>they can be made to co'exist, that would be substantially better.
>
>Thanks,
>Kevin
>
>From: Brandon Logan [brandon.lo...@rackspace.com]
>Sent: Tuesday, January 26, 2016 12:19 PM
>To: openstack-dev@lists.openstack.org
>Subject: Re: [openstack-dev] [openstack-ansible] LBaaSv2 / Octavia support
>
>Oh lbaas versioning was a big deal in the beginning.  Versioning an
>advanced service is a whole other topic and exposed many "interesting"
>issues with the neutron extension and service plugin framework.
>
>The reason v1 and v2 cannot be run together are mainly to get over an
>issue we had with the 2 different agents which woudl have caused a much
>larger refactor.  The v1 OR v2 requirement was basically a hack to get
>around that.  Now that Octavia is the reference implementation and the
>default, relaxing this restriction shouldn't cause any problems really.
>Although, I don't want to 100% guarantee that because it's been a while
>since I was in that world.
>
>If that were relaxed, the v2 agent and v1 agent could still be run at
>the same time which is something to think about.  Come to think about
>it, we might want to revisit whether the v2 and v1 agent running
>together is something that can be easily fixed because many things have
>improved since then AND my knowledge has obviously improved a lot since
>that time.
>
>Glad yall brought this up.
>
>Thanks,
>Brandon
>
>
>On Tue, 2016-01-26 at 14:07 -0600, Major Hayden wrote:
>> On 01/26/2016 02:01 PM, Fox, Kevin M wrote:
>> > I believe lbaas v1 and v2 are different then every other openstack api 
>> > version in that while you can run v1 and v2 at the same time but they are 
>> >