Open Stack

Hi Dani,

Can you please explain further the 3rd use case (Multiple FIPs….)?

Regards,
                -Sam.

From: Daniel Comnea [mailto:comnea.dani at gmail.com]
Sent: Friday, May 22, 2015 10:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

My $0.2 cents:

I echo what Maish said with regards to functionality:
- integration with HEAT is a must from Day -1 (if there is anything like this :) ) otherwise will be hard to gain operators traction. Look it as the entry point for everyone trying to move from Neutron LB
- white/ black listing traffic based on source port/ network/IP
- multiple FIPs associated with 1 LB, the use case is: say i have 1 LB open for port tcp 80 & udp 88 listening on 2 FIPs (even registered into a DNS) and 2 different set of clients consuming this interfaces - frontend and backend
Dani

Dani

On Thu, May 21, 2015 at 10:45 PM, Brandon Logan <brandon.logan at rackspace.com<mailto:brandon.logan at rackspace.com>> wrote:

​Right now its all or nothing as far as tcp ports go.  It currently does not have the functionality of white/black listinging traffic originating from a specific network.

________________________________
From: Maish Saidel-Keesing <maishsk at maishsk.com<mailto:maishsk at maishsk.com>>
Sent: Thursday, May 21, 2015 7:45 AM
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>

Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

Thanks Brandon
On 05/20/15 22:58, Brandon Logan wrote:

​Just to add a few things,

Barbican is not yet implemented in Octavia, though the code is there, we just need to spend a few hours hooking it all up and testing it out.



Also, the security groups are used by octavia right now so that only the ports on the listener are accessible.  Basically if a loadbalancer has listeners on ports 80 and 443, the vip ports will only allow traffic on those ports.  It shouldn't allow other traffic.
That is great to hear. I assume that if we are using security groups we will also be able to define rules regarding which networks the listeners are allowed to accept traffic from?

Is that assumption correct?




Thanks,

Brandon

________________________________
From: Doug Wiegley <dougwig at parksidesoftware.com><mailto:dougwig at parksidesoftware.com>
Sent: Thursday, May 21, 2015 12:49 AM
To: maishsk+openstack at maishsk.com<mailto:maishsk+openstack at maishsk.com>; OpenStack Development Mailing List (not for usage questions); Maish Saidel-Keesing
Subject: Re: [openstack-dev] [lbaas] [octavia] [barbican] Relationship between Octavia and Barbican and Octavia 1.0 questions

Hi Maish,

Thanks for the feedback, some answers below.  Please also be aware of the lbaas use cases session tomorrow at 9am (yuck, I know), https://etherpad.openstack.org/p/YVR-neutron-lbaas-use-cases


On May 19, 2015, at 12:05 AM, Maish Saidel-Keesing <maishsk at maishsk.com<mailto:maishsk at maishsk.com>> wrote:

Hello all,

Going over today's presentation "Load Balancing as a Service, Kilo and Beyond"[1] (great presentation!!) - there are a few questions I have regarding the future release:

For Octavia 1.0:

1. Can someone explain to me how the flow would work for spinning up a a new Amphora with regards to interaction between Neutron, LBaaS and Barbican?
Same question as well regarding how the standby is created and its relationship with Barbican.

The lbaas API runs inside neutron-server.  The general flow is:

- User interacts with neutron CLI/API or horizon (in liberty), and creates an LB.
- Lbaas plugin in neutron creates logical models, fetches cert data from barbican, and calls the backend lbaas driver.
- The backend driver does what it needs to to instantiate the LB. Today this is a synchronous call that waits for the nova boot, but by Liberty, it will likely be an async call to the octavia controller to finish the job.

Once Octavia has control, it is doing:

- Get REST calls for objects,
- Talk to nova, spin up an amphora image,
- Talk to neutron, plumb in the networks,
- Send the amphora its config.



2. Will the orchestration (Heat) also be implemented when Octavia 1.0 is released or only further down the line?
If not what would you suggest be the way to orchestrate LBaaS until this is ready?

We need to talk to the Heat folks and coordinate this, which we are planning to do soon.



3. Is there some kind of hook into Security groups also planned for the Amphora to also protect the Load Balancer?

Not at present, but I recorded this in the feature list on the etherpad above.



I think that based on the answers to these questions above - additional questions will follow.

Thanks

[1] https://www.youtube.com/watch?v=-eAKur8lErU
--
Best Regards,
Maish Saidel-Keesing
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Best Regards,
Maish Saidel-Keesing

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150526/29702916/attachment.html>