from:"Phillip Toohill"

Re: [openstack-dev] [Octavia] Questions about the Octavia project

2015-01-06 Thread Phillip Toohill

Ill answer inline what I can, others can chime in to clear up anything and
answer the rest. 

On 1/6/15 10:38 AM, "Andrew Hutchings"  wrote:

>Hi,
>
>I¹m looking into the Octavia project in relation to something my team are
>working on inside HP and I have a bunch of questions.  I realise it is
>early days for the project and some of these could be too low level at
>this time.
>
>Some of these questions come from the fact that I could not get the
>documentation to compile and the docs site for Octavia is down.  The
>v0.5-component-design.dot file crashes Graphviz 2.38 in every OS I tried
>and unfortunately all my dev machines have that version or 2.36 which is
>too low to render it correctly.  It also requires at least 5 extra
>dependencies (Sphinx modules) to build the docs but doesn¹t try to
>install them.
>
>I¹ll guess I¹ll start from the most obvious question:
>
>1. Octavia looks a lot like Libra but with integration into Neutron and
>Barbican (both were planned for Libra) as well as few other changes.  So
>the most obvious question is: why not just develop Libra for integration
>with Neutron?
There was many discussions with many contributors that included HP,
Rackspace, Bluebox A10 etc.. In regards to this decision. In the docs we
should have links to the reasonings behind some of these.
>
>Amphorae stuff:
>
>2. I see a lot of building blocks for the controller and Amphorae but not
>a lot about communication.  What protocol / method is to be used to
>communicate to the Amphorae instances?
In the docs/specs the communication protocols are defined.

>3. How are Amphorae instances to be spun up on-demand?  I see a reference
>to Heat but not sure if that is why it is there

The specs define how this is to happen

>4. There is mention of Docker in some of the deploy scripts.  Is this for
>multi-tenancy or just separation of the Amphorae processes?
>5. I take it Amphorae is designed to be single-AZ for now?
>
>Load Balancing:
>
>6. It seems like you are going to have SSL termination support and are
>going to use HAProxy, which means that you will have unencrypted data
>between the LB and web servers.  How do you plan to work around this
>problem?
Not sure what the 'problem' is, ultimately its up to the user, but a
private network can be configured between the LB and Web server
>
>Security:
>
>7. Someone in the specification there is talk of a 1 minute cache of
>security certificates.  How are you going to ensure that the cache will
>actually erase that cache after the 1 minute?  Also why cache them at
>all?  It seems to me to be a potential security risk
>
>API:
>
>8. More a comment than a question.  There is talk of using Pecan+WSME.
>Libra had a 5K patch on top of WSME just to make it behave correctly with
>Pecan and correct JSON specifications in certain situations, judging by
>the planned API you will also hit those same situations.  I admit I¹ve
>not looked at WSME for a year and there was an effort to strip it out of
>Libra completely at one point.  So that one is mainly my 2c :)
>
>Many thanks for your time.
>
>Kind Regards
>--
>Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/
>
>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] LBaaS Mid Cycle Sprint

2014-06-17 Thread Phillip Toohill

Everyone is migrating to the new channel #openstack-lbaas

From: Dustin Lundquist mailto:dus...@null-ptr.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, June 17, 2014 10:10 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] LBaaS Mid Cycle Sprint

Actually the channel name is #neutron-lbaas.


On Tue, Jun 17, 2014 at 8:03 AM, Kyle Mestery 
mailto:mest...@noironetworks.com>> wrote:
Also, pop into #openstack-lbaas on Freenode, we have people there
monitoring the channel.

On Tue, Jun 17, 2014 at 9:19 AM, Dustin Lundquist 
mailto:dus...@null-ptr.net>> wrote:
> We have an Etherpad going here:
> https://etherpad.openstack.org/p/juno-lbaas-mid-cycle-hackathon
>
>
> Dustin
>
>
> On Tue, Jun 17, 2014 at 4:05 AM, Avishay Balderman 
> mailto:avish...@radware.com>>
> wrote:
>>
>> Hi
>> As the lbass mid cycle sprint starts today, is there any way to track and
>> understand the progress (without flying to Texas... )
>>
>> Thanks
>>
>> Avishay
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question

2014-04-18 Thread Phillip Toohill

Hello Stephen,

One use case we have, which was actually a highly requested feature for our 
service, was to ensure that traffic within the internal cloud network was not 
passed in the clear. I believe this mainly stems from the customers security 
requirements. I understand this reasoning to allow a centralized place to 
correct/prevent potential SSL attacks while still assuring data is secure all 
the way to the backend. I could probably dig up more details if this isn't 
clear enough, but is the way I understand this particular feature.


Thanks,
Phil

From: Stephen Balukoff mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, April 18, 2014 10:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question

Howdy, folks!

Could someone explain to me the SSL usage scenario where it makes sense to 
re-encrypt traffic traffic destined for members of a back-end pool?  SSL 
termination on the load balancer makes sense to me, but I'm having trouble 
understanding why one would be concerned about then re-encrypting the traffic 
headed toward a back-end app server. (Why not just use straight TCP load 
balancing in this case, and save the CPU cycles on the load balancer?)

We terminate a lot of SSL connections on our load balancers, but have yet to 
have a customer use this kind of functionality.  (We've had a few ask about it, 
usually because they didn't understand what a load balancer is supposed to do-- 
and with a bit of explanation they went either with SSL termination on the load 
balancer + clear text on the back-end, or just straight TCP load balancing.)

Thanks,
Stephen


--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

2014-10-06 Thread Phillip Toohill

Hello All, 

I wanted to start a discussion on floating IP management and ultimately
decide how the LBaaS group wants to handle the association. 

There is a need to utilize floating IPs(FLIP) and its API calls to
associate a FLIP to the neutron port that we currently spin up. 

See DOCS here:

> http://docs.openstack.org/api/openstack-network/2.0/content/floatingip_create.html

Currently, LBaaS will make internal service calls (clean interface :/) to 
create and attach a Neutron port. 
The VIP from this port is added to the Loadbalancer object of the Load balancer 
configuration and returned to the user.

This creates a bit of a problem if we want to associate a FLIP with the port 
and display the FLIP to the user instead of
the ports VIP because the port is currently created and attached in the plugin 
and there is no code anywhere to handle the FLIP
association. 

To keep this short and to the point:

We need to discuss where and how we want to handle this association. I have a 
few questions to start it off. 

Do we want to add logic in the plugin to call the FLIP association API?

If we have logic in the plugin should we have configuration that identifies 
weather to use/return the FLIP instead the port VIP?

Would we rather have logic for FLIP association in the drivers?

If logic is in the drivers would we still return the port VIP to the user then 
later overwrite it with the FLIP? 
Or would we have configuration to not return the port VIP initially, but an 
additional query would show the associated FLIP.


Is there an internal service call for this, and if so would we use it instead 
of API calls? 


Theres plenty of other thoughts and questions to be asked and discussed in 
regards to FLIP handling, 
hopefully this will get us going. I'm certain I may not be completely 
understanding this and 
is the hopes of this email to clarify any uncertainties. 





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

2014-10-12 Thread Phillip Toohill

Hello all, 

Heres some additional diagrams and docs. Not incredibly detailed, but
should get the point across.

Feel free to edit if needed.

Once we come to some kind of agreement and understanding I can rewrite
these more to be thorough and get them in a more official place. Also, I
understand theres other use cases not shown in the initial docs, so this
is a good time to collaborate to make this more thought out.

Please feel free to ping me with any questions,

Thank you


Google DOCS link for FLIP folder:
https://drive.google.com/folderview?id=0B2r4apUP7uPwU1FWUjJBN0NMbWM&usp=sha
ring

-diagrams are draw.io based and can be opened from within Drive by
selecting the appropriate application.

On 10/7/14 2:25 PM, "Brandon Logan"  wrote:

>I'll add some more info to this as well:
>
>Neutron LBaaS creates the neutron port for the VIP in the plugin layer
>before drivers ever have any control.  In the case of an async driver,
>it will then call the driver's create method, and then return to the
>user the vip info.  This means the user will know the VIP before the
>driver even finishes creating the load balancer.
>
>So if Octavia is just going to create a floating IP and then associate
>that floating IP to the neutron port, there is the problem of the user
>not ever seeing the correct VIP (which would be the floating iP).
>
>So really, we need to have a very detailed discussion on what the
>options are for us to get this to work for those of us intending to use
>floating ips as VIPs while also working for those only requiring a
>neutron port.  I'm pretty sure this will require changing the way V2
>behaves, but there's more discussion points needed on that.  Luckily, V2
>is in a feature branch and not merged into Neutron master, so we can
>change it pretty easily.  Phil and I will bring this up in the meeting
>tomorrow, which may lead to a meeting topic in the neutron lbaas
>meeting.
>
>Thanks,
>Brandon
>
>
>On Mon, 2014-10-06 at 17:40 +, Phillip Toohill wrote:
>> Hello All, 
>> 
>> I wanted to start a discussion on floating IP management and ultimately
>> decide how the LBaaS group wants to handle the association.
>> 
>> There is a need to utilize floating IPs(FLIP) and its API calls to
>> associate a FLIP to the neutron port that we currently spin up.
>> 
>> See DOCS here:
>> 
>> > 
>>http://docs.openstack.org/api/openstack-network/2.0/content/floatingip_cr
>>eate.html
>> 
>> Currently, LBaaS will make internal service calls (clean interface :/)
>>to create and attach a Neutron port.
>> The VIP from this port is added to the Loadbalancer object of the Load
>>balancer configuration and returned to the user.
>> 
>> This creates a bit of a problem if we want to associate a FLIP with the
>>port and display the FLIP to the user instead of
>> the ports VIP because the port is currently created and attached in the
>>plugin and there is no code anywhere to handle the FLIP
>> association. 
>> 
>> To keep this short and to the point:
>> 
>> We need to discuss where and how we want to handle this association. I
>>have a few questions to start it off.
>> 
>> Do we want to add logic in the plugin to call the FLIP association API?
>> 
>> If we have logic in the plugin should we have configuration that
>>identifies weather to use/return the FLIP instead the port VIP?
>> 
>> Would we rather have logic for FLIP association in the drivers?
>> 
>> If logic is in the drivers would we still return the port VIP to the
>>user then later overwrite it with the FLIP?
>> Or would we have configuration to not return the port VIP initially,
>>but an additional query would show the associated FLIP.
>> 
>> 
>> Is there an internal service call for this, and if so would we use it
>>instead of API calls?
>> 
>> 
>> Theres plenty of other thoughts and questions to be asked and discussed
>>in regards to FLIP handling,
>> hopefully this will get us going. I'm certain I may not be completely
>>understanding this and
>> is the hopes of this email to clarify any uncertainties.
>> 
>> 
>> 
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

2014-10-15 Thread Phillip Toohill

after the VIP is successfully created on the LB, and 
just before the driver updates the VIP’s status as ACTIVE, it can create the 
FLIP. Of course, if the FLIP provisioning fails for any reason, the VIP still 
stands. It’ll be empty in the result, and the API will error out saying “VIP 
created but FLIP creation failed”. It must be manually deleted by another 
delete VIP call. We can’t afford to provision a FLIP before a VIP is active, 
for external traffic shouldn’t be taken while the VIP isn’t up yet. If the 
lines are getting hazy right now because of this callback model, let’s just 
focus on the point that we’re initiating FLIP creation in the driver layer 
while the code sits in the plugin layer because it will need to update the 
database. But in absolute terms, we’re doing it in the driver.


It is use case c) that is interesting. In this case, we should do all neutron 
based provisioning neither in the driver, nor in the plugin in neutron, rather, 
we should do this in Octavia, and in the Octavia controller to be specific. 
This is very important to note, because if customers are using this deployment 
(which today has the potential to be way greater in the near future than any 
other model simply because of the sheer existing customer base), we can’t be 
creating the FLIP in the plugin layer and have the controller reattempt it. 
Indeed, the controllers can change their code to not attempt this, but like 
just noted, it isn’t logically orderly to create the FLIP before creating the 
VIP successfully. So let’s leave this op to the driver.


I am guilty of not following the proceedings on the Octavia controller design 
due to internal work deadlines, but if I remember right, the design specified a 
controller being built to spawn and configure virtual HAProxy LB instances. If 
Octavia is not taking that route today, I think that the best place to do this 
provisioning would be as described above for a) and b).

>>>>These are good points! Having the FLIP creation in the driver or in 
>>>>Octavias case the controller code that manages the HA of the VLBs is a 
>>>>great idea. Would this mean though that we are bypassing Neutrons calls 
>>>>completely if we do this? Or would this be API calls made from the 
>>>>controller/driver to Neutron? If were bypassing neutron we should assume 
>>>>that the deployers environment has the plumbing set up for the FLIP pool 
>>>>and some kind of service that can be queried for the FLIP?



4) If logic is in the drivers would we still return the port VIP to the user 
then later overwrite it with the FLIP?


>> As described in 2), we always return the VIP port along with the FLIP info 
>> in API calls. Users like PaaS that sit on top of IaaS (Openstack) will only 
>> use the FLIP when they commission endpoints for their users, who will only 
>> be concerned with the FLIP.



5) Or would we have configuration to not return the port VIP initially, but an 
additional query would show the associated FLIP.


>> Not inclined to doing this :) It’s just another field associated with the 
>> VIP - an API call for it would be overkill.

>>>>Makes sense to me


6) Is there an internal service call for this, and if so would we use it 
instead of API calls?


>> Really depends on the core plugin you’re using - each plugin does this 
>> differently, but all you need to do is to simply call 
>> core_plugin.create_floatingip() and it should do everything for you - it 
>> should correctly create the FLIP entry in the db, then go to its backend (a 
>> controller or ovs or the L3 agent etc) which will correctly provision the 
>> necessary interfaces and/or program the required flow rules or iptables 
>> rules or equivalent and return success or failure.

>>>> I may need to dig into the docs a bit more, but if theres a 
>>>> core_plugin.associate_flip call as there is in the API then this would 
>>>> save us from writing API communications from the controller/driver if we 
>>>> go that route.



All said and done, the fact is that in LBaaS, as with many other components, we 
can always override the default plugin and driver layers and write our own and 
do whatever we want in them :) This allows vendors to rewrite implementations 
if they need to. Hopefully we’ll get the design well enough that they don’t 
have to do that in more than a few modules.


Hope this helps! Please do let me know if you have any questions or need more 
pointers with the extensions/neutron/etc.

>>>> Thanks for the response and information! I may have a few points 
>>>> fundamentally incorrect, which is reasoning for this discussion, so I do 
>>>> appreciate the time you've taken to discuss with me :)



Cheers!

Regards,

Vijay



On Mon, Oct 13, 2014

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

2014-10-15 Thread Phillip Toohill

No worries :)

Could you possibly clarify what you mean by the FLIP hosted directly on the LB?

Im currently assuming the FLIP pools are designated in Neutron at this point 
and we would simply be associating with the VIP port, I'm unsure the meaning of 
hosting FLIP directly on the LB.

Thank you for responses! There is definitely a more thought out discussion to 
be had, and glad these ideas are being brought up now rather than later.

From: Vijay Venkatachalam 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, October 15, 2014 9:38 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

I felt guilty after reading Vijay B. ’s reply :).
My apologies to have replied in brief, here are my thoughts in detail.

Currently LB configuration exposed via floating IP is a 2 step operation.
User has to first “create a VIP with a private IP” and then “creates a FLIP and 
assigns FLIP to private VIP” which would result in a DNAT in the gateway.
The proposal is to combine these 2 steps, meaning make DNATing operation as 
part of VIP creation process.

While this seems to be a simple proposal I think we should consider finer 
details.
The proposal assumes that the FLIP is implemented by the gateway through a DNAT.
We should also be open to creating a VIP with a FLIP rather than a private IP.
Meaning FLIP will be hosted directly by the LB appliance.

In essence, LBaaS plugin will create the FLIP for the VIP and let the driver 
know about the FLIP that should get implemented.
The drivers should have a choice of implementing in its own way.
It could choose to

1.   Implement via the traditional route. Driver creates a private IP, 
implements VIP as a private IP in the lb appliance and calls Neutron to 
implement DNAT (FLIP to private VIP )

2.   Implement VIP as a FLIP directly on the LB appliance. Here there is no 
private IP involved.

Pros:
Not much changes in the LBaaS API, there is only one IP as part of the VIP.
We can ensure backward compatibility with the driver as well by having Step (1) 
implemented in abstract driver.

Thanks,
Vjay

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: 15 October 2014 05:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Thanks for the doc.

The floating IP could be hosted directly by the lb backend/lb appliance as well?
It depends on the appliance deployment.

From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: 14 October 2014 21:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Nice diagrams. :-) Thanks. Susanne

On Mon, Oct 13, 2014 at 4:18 PM, Phillip Toohill 
mailto:phillip.tooh...@rackspace.com>> wrote:
Diagrams in jpeg format..

On 10/12/14 10:06 PM, "Phillip Toohill" 
mailto:phillip.tooh...@rackspace.com>>
wrote:

>Hello all,
>
>Heres some additional diagrams and docs. Not incredibly detailed, but
>should get the point across.
>
>Feel free to edit if needed.
>
>Once we come to some kind of agreement and understanding I can rewrite
>these more to be thorough and get them in a more official place. Also, I
>understand theres other use cases not shown in the initial docs, so this
>is a good time to collaborate to make this more thought out.
>
>Please feel free to ping me with any questions,
>
>Thank you
>
>
>Google DOCS link for FLIP folder:
>https://drive.google.com/folderview?id=0B2r4apUP7uPwU1FWUjJBN0NMbWM&usp=sh
>a
>ring
>
>-diagrams are draw.io<http://draw.io> based and can be opened from within 
>Drive by
>selecting the appropriate application.
>
>On 10/7/14 2:25 PM, "Brandon Logan" 
>mailto:brandon.lo...@rackspace.com>> wrote:
>
>>I'll add some more info to this as well:
>>
>>Neutron LBaaS creates the neutron port for the VIP in the plugin layer
>>before drivers ever have any control.  In the case of an async driver,
>>it will then call the driver's create method, and then return to the
>>user the vip info.  This means the user will know the VIP before the
>>driver even finishes creating the load balancer.
>>
>>So if Octavia is just going to create a floating IP and then associate
>>that floating IP to the neutron port, there is the problem of the user
>>not ever seeing the correct VIP (which would be the floating iP).
>>
>>So really, we need to have a very detailed discussion on what the
>>options are for us to get this t

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

2014-10-15 Thread Phillip Toohill

Ah, this makes sense. Guess I'm wondering more so how that’s configured and if 
it utilizes Neutron at all. And if it does how does it configure that.

I have some more research to do it seems ;)

Thanks for the clarification

From: Vijay Venkatachalam 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, October 15, 2014 1:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

> I'm unsure the meaning of hosting FLIP directly on the LB.

There can be LB appliances (usually physical appliance) that sit at the edge 
and is connected to receive floating IP traffic .

In such a case, the VIP/Virtual Server with FLIP  can be configured in the LB 
appliance.
Meaning, LB appliance is now the “owner” of the FLIP and will be responding to 
ARPs.

Thanks,
Vijay V.

From: Phillip Toohill [mailto:phillip.tooh...@rackspace.com]
Sent: 15 October 2014 23:16
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

No worries :)

Could you possibly clarify what you mean by the FLIP hosted directly on the LB?

Im currently assuming the FLIP pools are designated in Neutron at this point 
and we would simply be associating with the VIP port, I'm unsure the meaning of 
hosting FLIP directly on the LB.

Thank you for responses! There is definitely a more thought out discussion to 
be had, and glad these ideas are being brought up now rather than later.

From: Vijay Venkatachalam 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, October 15, 2014 9:38 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

I felt guilty after reading Vijay B. ’s reply :).
My apologies to have replied in brief, here are my thoughts in detail.

Currently LB configuration exposed via floating IP is a 2 step operation.
User has to first “create a VIP with a private IP” and then “creates a FLIP and 
assigns FLIP to private VIP” which would result in a DNAT in the gateway.
The proposal is to combine these 2 steps, meaning make DNATing operation as 
part of VIP creation process.

While this seems to be a simple proposal I think we should consider finer 
details.
The proposal assumes that the FLIP is implemented by the gateway through a DNAT.
We should also be open to creating a VIP with a FLIP rather than a private IP.
Meaning FLIP will be hosted directly by the LB appliance.

In essence, LBaaS plugin will create the FLIP for the VIP and let the driver 
know about the FLIP that should get implemented.
The drivers should have a choice of implementing in its own way.
It could choose to

1.  Implement via the traditional route. Driver creates a private IP, 
implements VIP as a private IP in the lb appliance and calls Neutron to 
implement DNAT (FLIP to private VIP )

2.  Implement VIP as a FLIP directly on the LB appliance. Here there is no 
private IP involved.

Pros:
Not much changes in the LBaaS API, there is only one IP as part of the VIP.
We can ensure backward compatibility with the driver as well by having Step (1) 
implemented in abstract driver.

Thanks,
Vjay

From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com]
Sent: 15 October 2014 05:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Thanks for the doc.

The floating IP could be hosted directly by the lb backend/lb appliance as well?
It depends on the appliance deployment.

From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: 14 October 2014 21:15
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Nice diagrams. :-) Thanks. Susanne

On Mon, Oct 13, 2014 at 4:18 PM, Phillip Toohill 
mailto:phillip.tooh...@rackspace.com>> wrote:
Diagrams in jpeg format..

On 10/12/14 10:06 PM, "Phillip Toohill" 
mailto:phillip.tooh...@rackspace.com>>
wrote:

>Hello all,
>
>Heres some additional diagrams and docs. Not incredibly detailed, but
>should get the point across.
>
>Feel free to edit if needed.
>
>Once we come to some kind of agreement and understanding I can rewrite
>these more to be thorough and get them in a more official place. Also, I
>understand theres other use cases not shown in the initial docs, so this
>is a good time to col

Re: [openstack-dev] [Neutron][LBaaS] and [Octavia] haproxy-1.5.0 is out

2014-06-20 Thread Phillip Toohill

Alright!!! I'll get to reworking the TLS support bp that didn't get too much 
attention. This is fantastic news, thanks for sharing!

From: Stephen Balukoff [sbaluk...@bluebox.net]
Sent: Friday, June 20, 2014 8:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] and [Octavia] haproxy-1.5.0 is out

The wait is over on this one!

-- Forwarded message --
From: Willy Tarreau mailto:w...@1wt.eu>>
Date: Thu, Jun 19, 2014 at 12:54 PM
Subject: [ANNOUNCE] haproxy-1.5.0
To: hapr...@formilux.org

Hi everyone,

The list has been unusually silent today, just as if everyone was waiting
for something to happen :-)

Today is a great day, the reward of 4 years of hard work. I'm announcing the
release of HAProxy 1.5.0.

For people who don't follow the development versions, here are the most
noticeable features that 1.5 brings over 1.4 :
  - native SSL support on both sides with SNI/NPN/ALPN and OCSP stapling.
  - IPv6 and UNIX sockets are supported everywhere
  - end-to-end HTTP keep-alive for better support of NTLM and improved
efficiency in static farms
  - HTTP/1.1 response compression (deflate, gzip) to save bandwidth
  - PROXY protocol versions 1 and 2 on both sides
  - data sampling on everything in request or response, including payload
  - ACLs can use any matching method with any input sample
  - maps and dynamic ACLs updatable from the CLI
  - stick-tables support counters to track activity on any input sample
  - custom format for logs, unique-id, header rewriting, and redirects
  - improved health checks (SSL, scripted TCP, check agent, ...)
  - much more scalable configuration supports hundreds of thousands of backends
and certificates without sweating

Since dev26, a few bugs were fixed, and some low-importance things were
integrated. Basic OCSP stapling support from Dirkjan and Emeric was
finally merged. Sasha's header replace actions were merged as well. I've
added a few more info in the stats page (avg response times) and CSV
output (health check status), added support for PROXY v2 on the accept
side, and added the "capture" action on tcp-request in order to log
contents such as SNI or payload. Rémi's dh-param was finally integrated.

People love numbers, so here are a few :

>From 1.4.0 to 1.5.0, we had :
  - 1574 calendar days (4 yr 3 mon)
  - 26 development versions (one every 2 months on average)
  - 540 bugs fixed (387 added during 1.5, 153 affecting 1.4 as well)
  - 2549 commits
  - 683 unique commit dates (at least this many days worked)
  - up to 24 commits per day
  - 69712 lines removed, 122279 lines added
  - many extremely useful bug reports (too many to list)
  - 73 code/doc contributors :

  Adrian Bridgett, Alex Davies, Aman Gupta, Andreas Kohn,
  Apollon Oikonomopoulos, Arnaud Cornet, Baptiste Assmann, Bertrand Jacquin,
  Bhaskar Maddala, Conrad Hoffmann, Cyril Bonté, Daniel Schultze,
  David BERARD, David Cournapeau, David S, David du Colombier, Delta Yeh,
  Dirkjan Bussink, Dmitry Sivachenko, Emeric Brun, Emmanuel Hocdet,
  Evan Broder, Finn Arne Gangstad, Gabor Lekeny, Geoff Bucar, Wei Zhao,
  Guillaume Castagnino, Guillaume de Lafond, Hervé COMMOWICK,
  Hiroaki Nakamura, James Voth, Jamie Gloudon, Jarno Huuskonen,
  Joe Williams, Joshua M. Clulow, Julien Vehent, Justin Karneges,
  Kevin Hester, Kevin Musker, Kristoffer Grönlund, Krzysztof Piotr Oledzki,
  Lukas Tribus, Marc-Antoine Perennou, Mark Lamourine, Mathieu Trudel,
  Michael Scherer, Neil Prockter, Nenad Merdanovic, Nick Chalk,
  Olivier Burgard, Oskar Stolc, Patrick Mézard, Pieter Baauw,
  Prach Pongpanich, Rauf Kuliyev, Remi Gacogne, Sagi Bashari, Sasha Pachev,
  Sean Carey, Sergiy Prykhodko, Simon Horman, Simone Gotti,
  Stathis Voukelatos, Tait Clarridge, Thierry Fournier, Todd Lyons,
  Vincent Bernat, William Lallemand, William Turner, Willy Tarreau,
  Yuxans Yao, Yves Lafon.

Additionally, we are very thankful to a few organisations who have sponsored
the development of certain advanced features which required to dedicate a
person or a team for a significant amount of time (I hope I have not missed
any) :
  - HAProxy Technologies (formerly Exceliance)
  - Loadbalancer.org
  - StackOverflow
  - SmartFile
  - SmugMug
  - ImageShack

Don't forget to offer a beer to your distro packagers who make your life
easier. It's hard to list them all, but if you don't build from sources,
you're likely running a package made and maintained by one of these people :
  - debian: Vincent Bernat, Apollon Oikonomopoulos, Prach Pongpanich
  - Fedora: Ryan O'hara
  - OpenSuSE: Marcus Rückert
  - other? just report yourself!

And last, I'd like to assign a special mention to our most active mailing
list supporters during that period who make the project a reality by off-
loading the support task from developers, and kindly help our 800 permanent
subscribers on a daily basis, BIG THANKS to you gu

Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend

2014-07-03 Thread Phillip Toohill

If the objects remain in 'PENDING_CREATE' until provisioned it would seem
that the process got stuck in that status and may be in a bad state from
user perspective. I like the idea of QUEUED or similar to reference that
the object has been accepted but not provisioned.

Phil

On 7/3/14 10:28 AM, "Brandon Logan"  wrote:

>With the new API and object model refactor there have been some issues
>arising dealing with the status of entities.  The main issue is that
>Listener, Pool, Member, and Health Monitor can exist independent of a
>Load Balancer.  The Load Balancer is the entity that will contain the
>information about which driver to use (through provider or flavor).  If
>a Listener, Pool, Member, or Health Monitor is created without a link to
>a Load Balancer, then what status does it have?  At this point it only
>exists in the database and is really just waiting to be provisioned by a
>driver/backend.
>
>Some possibilities discussed:
>A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name
>Entities just remain in PENDING_CREATE until provisioned by a driver
>Entities just remain in ACTIVE until provisioned by a driver
>
>Opinions and suggestions?
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Auth token in context

2014-07-17 Thread Phillip Toohill

Hello all,

I am wondering how to get the auth token from a user request passed down
to the context so it can potentially be used by the plugin or driver?

Thank you


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Auth token in context

2014-07-18 Thread Phillip Toohill

Excellent! Thank you for the response, I figured it was possible, just
concerned me to why everything else made it to context except for the
token. 

So to be clear, you agree that it should at least be passed to context and
because its not could be deemed a bug?

Thank you

On 7/18/14 2:03 AM, "joehuang"  wrote:

>Hello, Phillip.
>
>Currently, Neutron did not pass the token to the context. But Nova/Cinder
>did that. It's easy to do that, just 'copy' from Nova/Cinder.
>
>1.  How Nova/Cinder did that
>class NovaKeystoneContext(wsgi.Middleware)
>///or CinderKeystoneContext for cinder
> 
>  auth_token = req.headers.get('X_AUTH_TOKEN',
> req.headers.get('X_STORAGE_TOKEN'))
>  ctx = context.RequestContext(user_id,
> project_id,
> user_name=user_name,
> project_name=project_name,
> roles=roles,
> auth_token=auth_token,
> remote_address=remote_address,
> service_catalog=service_catalog)
>
>2.  Neutron not passed token. Also not good for the third part network
>infrastructure to integrate the authentication with KeyStone.
>class NeutronKeystoneContext(wsgi.Middleware)
>.
># token not get from the header and not passed to context. Just
>change here like what Nova/Cinder did.
>context.Context(user_id, tenant_id, roles=roles,
>  user_name=user_name,
>tenant_name=tenant_name,
>  request_id=req_id)
>req.environ['neutron.context'] = ctx
>
>I think I'd better to report a bug for your case.
>
>Best Regards
>Chaoyi Huang ( Joe Huang )
>-邮件原件-
>发件人: Phillip Toohill [mailto:phillip.tooh...@rackspace.com]
>发送时间: 2014年7月18日 14:07
>收件人: OpenStack Development Mailing List (not for usage questions)
>主题: [openstack-dev] [Neutron] Auth token in context
>
>Hello all,
>
>I am wondering how to get the auth token from a user request passed down
>to the context so it can potentially be used by the plugin or driver?
>
>Thank you
>
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Auth token in context

2014-07-18 Thread Phillip Toohill

It was for more of a potential use to query another service. Don't think well 
go this route though, but was curious why it was one of the only values not 
populated even though there's a field for it.

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, July 18, 2014 2:16 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Auth token in context

What are you trying to use the token to do?


On Fri, Jul 18, 2014 at 9:16 AM, Phillip Toohill 
mailto:phillip.tooh...@rackspace.com>> wrote:
Excellent! Thank you for the response, I figured it was possible, just
concerned me to why everything else made it to context except for the
token.

So to be clear, you agree that it should at least be passed to context and
because its not could be deemed a bug?

Thank you

On 7/18/14 2:03 AM, "joehuang" 
mailto:joehu...@huawei.com>> wrote:

>Hello, Phillip.
>
>Currently, Neutron did not pass the token to the context. But Nova/Cinder
>did that. It's easy to do that, just 'copy' from Nova/Cinder.
>
>1.  How Nova/Cinder did that
>class NovaKeystoneContext(wsgi.Middleware)
>///or CinderKeystoneContext for cinder
>
>  auth_token = req.headers.get('X_AUTH_TOKEN',
> req.headers.get('X_STORAGE_TOKEN'))
>  ctx = context.RequestContext(user_id,
> project_id,
> user_name=user_name,
> project_name=project_name,
> roles=roles,
> auth_token=auth_token,
> remote_address=remote_address,
> service_catalog=service_catalog)
>
>2.  Neutron not passed token. Also not good for the third part network
>infrastructure to integrate the authentication with KeyStone.
>class NeutronKeystoneContext(wsgi.Middleware)
>.
># token not get from the header and not passed to context. Just
>change here like what Nova/Cinder did.
>context.Context(user_id, tenant_id, roles=roles,
>  user_name=user_name,
>tenant_name=tenant_name,
>          request_id=req_id)
>req.environ['neutron.context'] = ctx
>
>I think I'd better to report a bug for your case.
>
>Best Regards
>Chaoyi Huang ( Joe Huang )
>-邮件原件-
>发件人: Phillip Toohill 
>[mailto:phillip.tooh...@rackspace.com<mailto:phillip.tooh...@rackspace.com>]
>发送时间: 2014年7月18日 14:07
>收件人: OpenStack Development Mailing List (not for usage questions)
>主题: [openstack-dev] [Neutron] Auth token in context
>
>Hello all,
>
>I am wondering how to get the auth token from a user request passed down
>to the context so it can potentially be used by the plugin or driver?
>
>Thank you
>
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Regarding v2 LoadBalancer's status(es)

2015-12-14 Thread Phillip Toohill

>Yeah this needs to be better documented.  I would say all of those
>statuses in the docs pertain to provisioning_status, except for
>INACTIVE, which I'm actually not sure where that is being used. ...

There is this patch to utilize the INACTIVE status: 
https://review.openstack.org/#/c/255875/ 



From: Brandon Logan 
Sent: Monday, December 14, 2015 6:25 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS] Regarding v2 LoadBalancer's 
status(es)

Hi Bryan,

On Mon, 2015-12-14 at 15:19 -0600, Bryan Jones wrote:
> Hi All,
>
> I had a few issues/questions regarding the statuses
> (provisioning_status and operating_status) of a v2 LoadBalancer. To
> preface these, I am working on the LBaaS v2 support in Heat.
>
> The first question regards the allowed values for each of
> provisioning_status and operating status. Here it seems the
> documentation is ambiguous. [1] provides a list of possible statuses,
> but does not mention if they are options for provisioning_status or
>  operating_status. [2] provides much clearer options for each status,
> but does not show the INACTIVE status mention in [1]. Should INACTIVE
> be included in the possible options for one of the statuses, or should
> it be removed from [1] altogether?

Yeah this needs to be better documented.  I would say all of those
statuses in the docs pertain to provisioning_status, except for
INACTIVE, which I'm actually not sure where that is being used.  I have
to plead ignorance on this.  I was initially thinking operating_status
but I don't see it being used.  So that probably needs to just be pulled
out of the docs entirely.  The operating_status statuses are listed in
code here [1].  They are pretty self explanatory, except for maybe
DEGRADED.  DEGRADED basically means that one or more of its descendants
are in an OFFLINE operating_status.  NO_MONITOR means no health monitor
so operating_status can't be evaluated.  DISABLED means admin_state_up
on that entity is set to False.

>
> Second, [1] also mentions that an error_details attribute will be
> provided if the status is ERROR. I do not see any error_details
> attribute in the LoadBalancer code [3], so I am wondering where that
> attribute comes from?

This is actually something that was in v1 (status_description) that we
have not added to v2.  It would be nice to have but its not there yet.
The docs should be updated to remove this.
>
> Finally, I'm curious what operations can be performed on the
> LoadBalancer if the operating_status is OFFLINE and the
> provisioning_status is ACTIVE. First is this state possible? And
> second, can the LoadBalancer be manipulated (i.e. add a Listener to
> the LoadBalancer) if it is in this state?

Operations on a load balancer are only restricted based on the
provisioning_status.  operating_status is purely for information.  If
the load balancer's provisioning status is ACTIVE then you can do any
operation on it, regardless of operating_status.

I don't know of a current scenario where ACTIVE/OFFLINE status is
actually possible for a load balancer, but a driver could decide to do
that, though I'd like to understand that use case first.

>
> [1]
> http://developer.openstack.org/api-ref-networking-v2-ext.html#lbaas-v2.0
> [2]
> http://developer.openstack.org/api-ref-networking-v2-ext.html#showLoadBalancerv2
> [3]
> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/services/loadbalancer/data_models.py#L503
>
> Thanks,
>
> BRYAN JONES
> Software Engineer - OpenStack Development
>
> ___
> Phone: 1-507-253-2620
> E-mail: jone...@us.ibm.com
> Find me on: LinkedIn:
> http://www.linkedin.com/in/bjones17/
> IBM
>
>   3605 Hwy 52 N
>Rochester, MN 55901-1407
>   United States
>
>
>
>
> __
> 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


[1]
https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/services/loadbalancer/constants.py#L100

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
__
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] [neutron][lbaas] questions about scenario tests

2015-07-27 Thread Phillip Toohill

?Wonder if this is the same behavior as the TLS scenario? I have some higher 
priorities but I am attempting to debug the TLS test in between doing other 
things. Ill let you know if I come across anything.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374


From: Madhusudhan Kandadai 
Sent: Sunday, July 26, 2015 10:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] questions about scenario tests

Hi there,

We have two working scenario tests in neutron lbaas tree and those are getting 
succeeded locally, however when running them in Jenkins, it is behaving 
differently: One of them got passed and the other one is facing  time-out 
issues when trying to curl two backend servers after setting up two simple 
webservers. Both the tests are using the same base.py to setup backend servers. 
For info: 
https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/tests/tempest/v2/scenario

Tried increasing the default ping_timeout from 120 to 180, but no luck. Their 
logs are shown here: 
http://logs.openstack.org/13/205713/4/experimental/gate-neutron-lbaasv2-dsvm-scenario/09bbbd1/

If anyone has any idea about this, could you shed some light on the same?

Thanks!

Madhu
__
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] [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas core team

2015-09-16 Thread Phillip Toohill

+1

Phillip V. Toohill III
Software Developer

phone: 210-312-4366
mobile: 210-440-8374



From: Eichberger, German [german.eichber...@hpe.com]
Sent: Wednesday, September 16, 2015 5:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for 
neutron-lbaas core team

Great news! From the Octavia end I totally support that choiceŠ

German

On 9/16/15, 3:40 PM, "Al Miller"  wrote:

>+1
>
>Al
>
>
>> -Original Message-
>> From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
>> Sent: Wednesday, September 16, 2015 3:34 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for
>> neutron-lbaas core team
>>
>> Hi all,
>>
>> As the Lieutenant of the advanced services, I nominate Michael Johnson
>>to
>> be a member of the neutron-lbaas core reviewer team.
>>
>> Review stats are in line with other cores[2], and Michael has been
>> instrumental in both neutron-lbaas and octavia.
>>
>> Existing cores, please vote +1/-1 for his addition to the team (that¹s
>>Brandon,
>> Phil, Al, and Kyle.)
>>
>> Thanks,
>> doug
>>
>> 1. http://docs.openstack.org/developer/neutron/policies/core-
>> reviewers.html#core-review-hierarchy
>> 2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>>
>>
>> __
>> 
>> 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] [neutron][lbaas]Error at listener's barbican container validation

2015-06-04 Thread Phillip Toohill

I think there may just be some non-updated docstrings here. We should take only 
the 'ref'. If we get a UUID we wont know how to build it or what to do with it. 
The naming of this does need to change, but I dont' believe we need to convert 
UUID to ref.


Is 'self.get_cert_ref_url(cert_ref)' something already available that i may be 
over looking or an example?


IMO, we need to go through and make sure the 'container_ref' is updated to be 
consistent throughout the project for the barbican stuff and is something I 
plan on doing once I get a chance if no body else does.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374


From: santosh sharma 
Sent: Thursday, June 4, 2015 12:08 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas]Error at listener's barbican container 
validation


There is error while validating the barabican containers associated with 
listener (tls and sni container) at plugin layer.

In validate_tls_container() ,contain_id is passed where as it is expecting 
container_ref_url.

 def _validate_tls(self, listener, curr_listener=None):

def validate_tls_container(container_ref):
...

   def validate_tls_containers(to_validate):
for container_ref in to_validate:
validate_tls_container(container_ref)
   ...
   if len(to_validate) > 0:
validate_tls_containers(to_validate)

#to_validate is list of container_ids.

# barbican_cert_manager.py  ,at  get_cert()  cert_ref is  UUID instead of 
ref_url for container.

def get_cert(cert_ref, service_name='Octavia', resource_ref=None,
 check_only=False, **kwargs):

 ...
 :param cert_ref: the UUID of the cert to retrieve
 ...

 cert_container = connection.containers.get(
container_ref=cert_ref

#above container_ref is a UUID whereas connection.container.get() expects a 
reference url.

We should prepare ref_url from container UUID before passing to barbican client 
apis.
following should fix the issue.

diff --git a/neutron_lbaas/common/cert_manager/barbican_cert_manager.py 
b/neutron_lbaas/common/cert_manager/barbican_cert_manager.py
index 1ad38ee..8d3c3c4 100644
--- a/neutron_lbaas/common/cert_manager/barbican_cert_manager.py
+++ b/neutron_lbaas/common/cert_manager/barbican_cert_manager.py
@@ -219,6 +222,9 @@ class CertManager(cert_manager.CertManager):
 """
 connection = BarbicanKeystoneAuth.get_barbican_client()

+if self.is_UUID(cert_ref):
+cert_ref = self.get_cert_ref_url(cert_ref)
+

Error log:
---
ERROR neutron_lbaas.common.cert_manager.barbican_cert_manager 
[req-a5e704fb-f04b-45f2-9c50-f3bfebe09afd admin 5ca9f
cbf4652456a9bd53582b86bd0e9] Error getting 0b8d5af0-c156-46ad-b4c6-882a84824ce2
2015-06-04 09:58:38.126 TRACE 
neutron_lbaas.common.cert_manager.barbican_cert_manager Traceback (most recent 
call last):
2015-06-04 09:58:38.126 TRACE 
neutron_lbaas.common.cert_manager.barbican_cert_manager   File 
"/opt/stack/neutron-lbaas/neutron_lbaas/common
/cert_manager/barbican_cert_manager.py", line 228, in get_cert
2015-06-04 09:58:38.126 TRACE 
neutron_lbaas.common.cert_manager.barbican_cert_manager 
container_ref=cert_ref
2015-06-04 09:58:38.126 TRACE 
neutron_lbaas.common.cert_manager.barbican_cert_manager   File 
"/opt/stack/python-barbicanclient/barbicanclie
nt/containers.py", line 528, in get
2015-06-04 09:58:38.126 TRACE 
neutron_lbaas.common.cert_manager.barbican_cert_manager 
base.validate_ref(container_ref, 'Container')
2015-06-04 09:58:38.126 TRACE 
neutron_lbaas.common.cert_manager.barbican_cert_manager   File 
"/opt/stack/python-barbicanclient/barbicanclie
nt/base.py", line 35, in validate_ref
2015-06-04 09:58:38.126 TRACE 
neutron_lbaas.common.cert_manager.barbican_cert_manager raise 
ValueError('{0} incorrectly specified.'.for
mat(entity))
2015-06-04 09:58:38.126 TRACE 
neutron_lbaas.common.cert_manager.barbican_cert_manager ValueError: Container 
incorrectly specified.
2015-06-04 09:58:38.126 TRACE 
neutron_lbaas.common.cert_manager.barbican_cert_manager
2015-06-04 09:58:38.167 INFO neutron.api.v2.resource 
[req-a5e704fb-f04b-45f2-9c50-f3bfebe09afd admin 
5ca9fcbf4652456a9bd53582b86bd0e9] crea
te failed (client error): TLS container 0b8d5af0-c156-46ad-b4c6-882a84824ce2 
could not be found
---
--

Thanks
Santosh
__
OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for neutron-lbaas core team

2015-07-02 Thread Phillip Toohill



Phillip V. Toohill III
Software Developer

phone: 210-312-4366
mobile: 210-440-8374



From: Eichberger, German [german.eichber...@hp.com]
Sent: Thursday, July 2, 2015 5:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for 
neutron-lbaas core team

Al has been a great asset to LBaaS. Well deserved! +1000

German
+1

On 7/2/15, 3:16 PM, "Doug Wiegley"  wrote:

>Hi all,
>
>As the Lieutenant of the advanced services, I would like to nominate Al
>Miller to be a member of the neutron-lbaas core reviewer team.
>
>Review stats are in line with other cores[2] and feedback on patches has
>been great. Additionally, he has been instrumental in our devstack
>support and octavia work.
>
>Existing cores, please vote +1/-1 for his addition to the team (that¹s
>Brandon, Phil, and Kyle.)
>
>Thanks,
>doug
>
>1.
>http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#c
>ore-review-hierarchy
>2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>__
>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] [neutron][lbaas] Proposing Al Miller for neutron-lbaas core team

2015-07-02 Thread Phillip Toohill

I think I bottom posted somehow. 

+1 for Al!

Phillip V. Toohill III
Software Developer

phone: 210-312-4366
mobile: 210-440-8374



From: Brandon Logan 
Sent: Thursday, July 2, 2015 6:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for 
neutron-lbaas core team

+1 for me.  Phil your message did not come through.

On 7/2/15, 6:32 PM, "Phillip Toohill" 
wrote:

>
>
>Phillip V. Toohill III
>Software Developer
>
>phone: 210-312-4366
>mobile: 210-440-8374
>
>
>
>From: Eichberger, German [german.eichber...@hp.com]
>Sent: Thursday, July 2, 2015 5:24 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for
>neutron-lbaas core team
>
>Al has been a great asset to LBaaS. Well deserved! +1000
>
>German
>+1
>
>On 7/2/15, 3:16 PM, "Doug Wiegley"  wrote:
>
>>Hi all,
>>
>>As the Lieutenant of the advanced services, I would like to nominate Al
>>Miller to be a member of the neutron-lbaas core reviewer team.
>>
>>Review stats are in line with other cores[2] and feedback on patches has
>>been great. Additionally, he has been instrumental in our devstack
>>support and octavia work.
>>
>>Existing cores, please vote +1/-1 for his addition to the team (that¹s
>>Brandon, Phil, and Kyle.)
>>
>>Thanks,
>>doug
>>
>>1.
>>http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#
>>c
>>ore-review-hierarchy
>>2. http://stackalytics.com/report/contribution/neutron-lbaas/90
>>_
>>_
>>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

__
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] [Neutron][LBaaS][barbican]TLS container could not be found

2016-02-29 Thread Phillip Toohill

We could use some more information.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374




From: Madhusudhan Kandadai 
Sent: Monday, February 29, 2016 3:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not 
be found

Wondering, have you guys figured out this issue? I am seeing the same problem 
that Jiahao is getting.

On Thu, Feb 4, 2016 at 9:53 AM, Adam Harwell 
mailto:adam.harw...@rackspace.com>> wrote:

Could you provide your neutron-lbaas.conf? Depending on what version you're 
using, barbican may not be the default secret backend (I believe this has been 
fixed). Alternatively, it depends on what user accounts are involved -- this 
should definitely work if you are using only the single admin account, but we 
haven't done a lot of testing around the ACLs yet to make sure they are working 
(and I believe there is still an outstanding bug in Barbican that would cause 
the ACLs to not function properly in our use-case).


--Adam



From: Jiahao Liang 
mailto:jiahao.li...@oneconvergence.com>>
Sent: Thursday, January 28, 2016 12:18 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be 
found

Hi community,

I was going through 
https://wiki.openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer
 with devstack. I was stuck at a point when I tried to create a listener within 
a loadbalancer with this command:

neutron lbaas-listener-create --loadbalancer lb1 --protocol-port 443 --protocol 
TERMINATED_HTTPS --name listener1 --default-tls-container=$(barbican secret 
container list | awk '/ tls_container / {print $2}')

But the command failed with output:

TLS container 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
could not be found

When I run:

barbican secret container list

I was able to see the corresponding container in the list and the status is 
active.
(Sorry, the format is a little bit ugly.)
+++---++-+-+---+
| Container href
 | Name   | Created   | Status | Type| Secrets  
   
| Consumers |
+++---++-+-+---+
| 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
| tls_container  | 2016-01-28 04:58:42+00:00 | ACTIVE | certificate | 
private_key=http://192.168.100.149:9311/v1/secrets/1bbe33fc-ecd2-43e5-82ce-34007b9f6bfd
 | None  |
|   
 ||   || | 
certificate=http://192.168.100.149:9311/v1/secrets/6d0211c6-8515-4e55-b1cf-587324a79abe
 |   |
| 
http://192.168.100.149:9311/v1/containers/31045466-bf7b-426f-9ba8-135c260418ee 
| tls_container2 | 2016-01-28 04:59:05+00:00 | ACTIVE | certificate | 
private_key=http://192.168.100.149:9311/v1/secrets/dba18cbc-9bfe-499e-931e-90574843ca10
 | None  |
|   
 ||   || | 
certificate=http://192.168.100.149:9311/v1/secrets/23e11441-d119-4b24-a288-9ddc963cb698
 |   |
+++---++-+-+---+


Also, if I did a GET method from a RESTful client with correct X-Auth-Token to 
the url: 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e3, 
I was able to receive the JSON information of the TLS container.


Anybody could give some advice on how to fix this problem?

Thank you in advance!

Best,
Jiahao Liang

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

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

2016-02-29 Thread Phillip Toohill

To further my thoughts, as Adam mentioned, it could be a user issue, which to 
me is what it sounds like. So being able to view the config and have other 
information is pertinent to solving the issue.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374




From: Phillip Toohill 
Sent: Monday, February 29, 2016 3:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not 
be found


We could use some more information.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374




From: Madhusudhan Kandadai 
Sent: Monday, February 29, 2016 3:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not 
be found

Wondering, have you guys figured out this issue? I am seeing the same problem 
that Jiahao is getting.

On Thu, Feb 4, 2016 at 9:53 AM, Adam Harwell 
mailto:adam.harw...@rackspace.com>> wrote:

Could you provide your neutron-lbaas.conf? Depending on what version you're 
using, barbican may not be the default secret backend (I believe this has been 
fixed). Alternatively, it depends on what user accounts are involved -- this 
should definitely work if you are using only the single admin account, but we 
haven't done a lot of testing around the ACLs yet to make sure they are working 
(and I believe there is still an outstanding bug in Barbican that would cause 
the ACLs to not function properly in our use-case).


--Adam



From: Jiahao Liang 
mailto:jiahao.li...@oneconvergence.com>>
Sent: Thursday, January 28, 2016 12:18 AM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be 
found

Hi community,

I was going through 
https://wiki.openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer
 with devstack. I was stuck at a point when I tried to create a listener within 
a loadbalancer with this command:

neutron lbaas-listener-create --loadbalancer lb1 --protocol-port 443 --protocol 
TERMINATED_HTTPS --name listener1 --default-tls-container=$(barbican secret 
container list | awk '/ tls_container / {print $2}')

But the command failed with output:

TLS container 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
could not be found

When I run:

barbican secret container list

I was able to see the corresponding container in the list and the status is 
active.
(Sorry, the format is a little bit ugly.)
+++---++-+-+---+
| Container href
 | Name   | Created   | Status | Type| Secrets  
   
| Consumers |
+++---++-+-+---+
| 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
| tls_container  | 2016-01-28 04:58:42+00:00 | ACTIVE | certificate | 
private_key=http://192.168.100.149:9311/v1/secrets/1bbe33fc-ecd2-43e5-82ce-34007b9f6bfd
 | None  |
|   
 ||   || | 
certificate=http://192.168.100.149:9311/v1/secrets/6d0211c6-8515-4e55-b1cf-587324a79abe
 |   |
| 
http://192.168.100.149:9311/v1/containers/31045466-bf7b-426f-9ba8-135c260418ee 
| tls_container2 | 2016-01-28 04:59:05+00:00 | ACTIVE | certificate | 
private_key=http://192.168.100.149:9311/v1/secrets/dba18cbc-9bfe-499e-931e-90574843ca10
 | None  |
|   
 ||   || | 
certificate=http://192.168.100.149:9311/v1/secret

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

2016-02-29 Thread Phillip Toohill

.controllers id=entity_id))
2016-02-29 13:43:17.398 TRACE barbican.api.controllers HTTPNotFound: Not Found. 
Sorry but your container is in another castle.
2016-02-29 13:43:17.398 TRACE barbican.api.controllers
2016-02-29 13:43:17.403 INFO barbican.api.middleware.context 
[req-0554f272-f711-49b7-a1f7-3b8bc87b431b afaa5d797f3543369d05e370a543ef9d 
c141e106a7424d1a8316cf03a8c91e40] Processed request: 404 Not Found - POST 
http://192.168.109.129:9311/v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/
{address space usage: 220770304 bytes/210MB} {rss usage: 101371904 bytes/96MB} 
[pid: 52558|app: 0|req: 76/76] 192.168.109.129 () {34 vars in 598 bytes} [Mon 
Feb 29 13:43:17 2016] POST 
/v1/containers/d96dccd5-0d39-4f67-ba3a-366a84cfd371/consumers/ => generated 111 
bytes in 63 msecs (HTTP/1.1 404) 4 headers in 179 bytes (1 switches on core 0)




On Mon, Feb 29, 2016 at 1:40 PM, Phillip Toohill 
mailto:phillip.tooh...@rackspace.com>> wrote:

To further my thoughts, as Adam mentioned, it could be a user issue, which to 
me is what it sounds like. So being able to view the config and have other 
information is pertinent to solving the issue.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374




From: Phillip Toohill 
mailto:phillip.tooh...@rackspace.com>>
Sent: Monday, February 29, 2016 3:33 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not 
be found


We could use some more information.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374




From: Madhusudhan Kandadai 
mailto:madhusudhan.openst...@gmail.com>>
Sent: Monday, February 29, 2016 3:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not 
be found

Wondering, have you guys figured out this issue? I am seeing the same problem 
that Jiahao is getting.

On Thu, Feb 4, 2016 at 9:53 AM, Adam Harwell 
mailto:adam.harw...@rackspace.com>> wrote:

Could you provide your neutron-lbaas.conf? Depending on what version you're 
using, barbican may not be the default secret backend (I believe this has been 
fixed). Alternatively, it depends on what user accounts are involved -- this 
should definitely work if you are using only the single admin account, but we 
haven't done a lot of testing around the ACLs yet to make sure they are working 
(and I believe there is still an outstanding bug in Barbican that would cause 
the ACLs to not function properly in our use-case).


--Adam



From: Jiahao Liang 
mailto:jiahao.li...@oneconvergence.com>>
Sent: Thursday, January 28, 2016 12:18 AM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be 
found

Hi community,

I was going through 
https://wiki.openstack.org/wiki/Network/LBaaS/docs/how-to-create-tls-loadbalancer
 with devstack. I was stuck at a point when I tried to create a listener within 
a loadbalancer with this command:

neutron lbaas-listener-create --loadbalancer lb1 --protocol-port 443 --protocol 
TERMINATED_HTTPS --name listener1 --default-tls-container=$(barbican secret 
container list | awk '/ tls_container / {print $2}')

But the command failed with output:

TLS container 
http://192.168.100.149:9311/v1/containers/d8b25d56-4fc5-406d-8b2d-5a85de2a1e34 
could not be found

When I run:

barbican secret container list

I was able to see the corresponding container in the list and the status is 
active.
(Sorry, the format is a little bit ugly.)
+++---++-+-+---+
| Container href
 | Name   | Created   | Status | Type| Secrets  
   
| Consumers |
+++---++-+-+---+
| 
http://192.168.100.149:9311/v1/containers/d8

Re: [openstack-dev] [neutron] [lbaas] LBaaS Haproxy performance benchmarking

2015-02-04 Thread Phillip Toohill

+1 for Tsung!


From: Adam Harwell 
mailto:adam.harw...@rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, February 4, 2015 9:25 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [lbaas] LBaaS Haproxy performance 
benchmarking

At Rackspace we have been working on automated testing with Ansible and Tsung, 
but I don’t know if that code ever made it to a public repository… We found 
Tsung to be very useful for parallel testing though! :)

--Adam

https://keybase.io/rm_you


From: Varun Lodaya mailto:varun_lod...@symantec.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, February 3, 2015 at 6:58 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron] [lbaas] LBaaS Haproxy performance 
benchmarking

Hi,

We were trying to use haproxy as our LBaaS solution on the overlay. Has anybody 
done some baseline benchmarking with LBaaSv1 haproxy solution?

Also, any recommended tools which we could use to do that?

Thanks,
Varun
__
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] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

2015-02-04 Thread Phillip Toohill

Sharing/reusing pools is a planned future feature. We are currently trying to 
work towards getting something released and having shared pools would extend 
that timeline to not meet our expectations.

From: Vijay Venkatachalam 
mailto:vijay.venkatacha...@citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, February 4, 2015 12:19 PM
To: "doug...@parkside.io" 
mailto:doug...@parkside.io>>, "OpenStack Development 
Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to 
driver when entities get associated/disassociated with root entity?

Thanks Doug.

My apologies for the delayed reply.

The change is merged, so replying here.

It is a welcome change in one way, there is always a root entity now in 
perspective while creating any entity.
Listener is created with loadbalancer and pool is created with listener.
The problem itself is eliminated because there is no DEFERRED stage.

But, this restricts pool in one listener. Basically reusing of a pools across 
listeners and loadbalancers is not possible now.

The use case of creating both a HTTPS vip and HTTP vip for the same pool is 
lost.

Basically, a user who will need that, should create 2 pools with the same 
members and manage them. Is that right?

Thanks,
Vijay V.

From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Tuesday, February 3, 2015 10:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to 
driver when entities get associated/disassociated with root entity?

I’d recommend taking a look at Brandon’s review: 
https://review.openstack.org/#/c/144834/

which aims to simplify exactly what you’re describing. Please leave feedback 
there.

Thanks,
doug

On Tue, Feb 3, 2015 at 7:13 AM, Vijay Venkatachalam 
mailto:vijay.venkatacha...@citrix.com>> wrote:
Hi:

In OpenStack neutron lbaas implementation, when entities are created/updated by 
the user, they might not be associated with the root entity, which is 
loadbalancer.
Since root entity has the driver information, the driver cannot be called by 
lbaas plugin during these operations by user.
Such entities are set in DEFFERED status until the entity is associated with 
root entity.
During this association operation (listener created with pool), the driver api 
is called for the current operation (listener create); and the driver is 
expected to perform the original operation (pool create) along with the current 
operation (listener create).
This leads to complex handling at the driver, I think it will be better for the 
lbaas plugin to call the original operation (pool create) driver API in 
addition to the current operation (listener create) API during the association 
operation.

That is the summary, please read on to understand the situation in detail.

Let’s take the example of pool create in driver.

a.   A pool create operation will not translate to a pool create api in the 
driver. There is a pool create in the driver API but that is never called today.

b.  When a listener is created with loadbalancer and pool, the driver’s 
listener create api is called and the driver is expected to create both pool 
and listener.

c.   When a listener is first created without loadbalancer but with a pool, 
the call does not reach driver. Later when the listener is updated with 
loadbalancer id,  the drivers listener update  API is called and the driver is 
expected to create both pool and listener.

d.  When a listener configured with pool and loadbalancer is updated with new 
pool id,  the driver’s listener update api is called. The driver is expected to 
delete the original pool that was associated, create the new pool and  also 
update the listener

As you can see this is leading to a quite a bit of handling in the driver code. 
This makes driver code complex.

How about handling this logic in lbaas plugin and it can call the “natural” 
functions that were deferred.

Whenever an entity is going from a DEFERRED to ACTIVE/CREATE status (through 
whichever workflow) the plugin can call the CREATE pool function of the driver.
Whenever an entity is going from an ACTIVE/CREATED to DEFERRED status (through 
whichever workflow) the plugin can call the DELETE pool function of the driver.

Thanks,
Vijay V.

__
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)
U

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

2015-04-07 Thread Phillip Toohill

?Hey Evgeny,


I believe Vivek is working on Horizon lbaasv2 support. We werent given a 
timeline or anything but sounds like its being actively worked on. I would 
reach out to him to get better timelines if concerned.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rackcdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374


From: Evgeny Fedoruk 
Sent: Tuesday, April 7, 2015 5:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

Hi guys,

LBaaS v2 has no horizon support as for now and I want to know if this work is 
planned to be done and , if yes, in what time frame.
Is there a plan to develop it for Kilo or for L release?

Thanks,
Evg
__
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] [neutron][lbaas] adding lbaas core

2015-04-21 Thread Phillip Toohill

Thank you!

Phillip V. Toohill III
Software Developer

phone: 210-312-4366
mobile: 210-440-8374



From: Brandon Logan 
Sent: Tuesday, April 21, 2015 11:57 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core

Welcome Phil!

From: Doug Wiegley 
Sent: Tuesday, April 21, 2015 11:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] adding lbaas core

It’s been a week, welcome Phil.

Thanks,
doug


> On Apr 13, 2015, at 2:39 PM, Doug Wiegley  
> wrote:
>
> Hi all,
>
> I'd like to nominate Philip Toohill as a neutron-lbaas core. Good guy, did a 
> bunch of work on the ref impl for lbaasv2, and and I'll let the numbers[1] 
> speak for themselves.
>
> Existing lbaas cores, please vote.  All three of us.  :-)
>
> [1] http://stackalytics.com/report/contribution/neutron-lbaas/30
>
> Thanks,
> doug
>
>


__
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-dev] [lbaas] [octavia] Proposing Lubosz Kosnik (diltram) as Octavia Core

2016-10-12 Thread Phillip Toohill


+1 good choice!
__
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] [Octavia] Questions about the Octavia project

Re: [openstack-dev] [Neutron][LBaaS] LBaaS Mid Cycle Sprint

Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question

[openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Re: [openstack-dev] [Neutron][LBaaS][Octavia] Floating IP management

Re: [openstack-dev] [Neutron][LBaaS] and [Octavia] haproxy-1.5.0 is out

Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend

[openstack-dev] [Neutron] Auth token in context

Re: [openstack-dev] [Neutron] Auth token in context

Re: [openstack-dev] [Neutron] Auth token in context

Re: [openstack-dev] [Neutron][LBaaS] Regarding v2 LoadBalancer's status(es)

Re: [openstack-dev] [neutron][lbaas] questions about scenario tests

Re: [openstack-dev] [neutron][lbaas] Proposing Michael Johnson for neutron-lbaas core team

Re: [openstack-dev] [neutron][lbaas]Error at listener's barbican container validation

Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for neutron-lbaas core team

Re: [openstack-dev] [neutron][lbaas] Proposing Al Miller for neutron-lbaas core team

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

Re: [openstack-dev] [Neutron][LBaaS][barbican]TLS container could not be found

Re: [openstack-dev] [neutron] [lbaas] LBaaS Haproxy performance benchmarking

Re: [openstack-dev] [neutron][lbaas] Can entity calls be made to driver when entities get associated/disassociated with root entity?

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

Re: [openstack-dev] [neutron][lbaas] adding lbaas core

[openstack-dev] [lbaas] [octavia] Proposing Lubosz Kosnik (diltram) as Octavia Core

27 matches

Site Navigation

Mail list logo

Footer information