Open Stack

Thanks Doug! PSB my comments within.

On 05/20/15 22:49, Doug Wiegley wrote:
> 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
>
Sorry but I will not be able to attend - I will be on a plane. I will 
look monitor the etherpad and pass my comments on.
>
>> 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 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.
 From this I gather that there is a dependency on Barbican. From what I 
found - this thread looks like the HA modelling for barbican [1]. Seems 
to me to be quite solid.

There was one detail that aroused my attention. Barbican is using 
PostgreSQL as the backend database [2].
Is there any specific reason why PostgreSQL and not MySQL like the rest 
of OpenStack? Is there any tehnical limitation that specifically 
requires PostgreSQL?

*From an operators perspective inducing a new database technology (yet 
again) this will is not ideal to say the least.*
> - 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.
Great! It would be ideal that this is available from Day 1, otherwise 
there will be no real to utilize this in production use cases.
>
>>
>> 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.
Much obliged - this is a basic security requirement that should be in 
place to protect/shield the load balancers from unwanted traffic.

[1] http://lists.openstack.org/pipermail/openstack/2014-March/006102.html
[2] https://github.com/cloudkeep/barbican/wiki/Architecture

-- 
Best Regards,
Maish Saidel-Keesing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150521/35d3d5af/attachment.html>