Open Stack

I think we can discuss backward compatibility further.

So the gist of the feature is that loadbalancer resource is introduced that
should be created first and becomes the root object of the existing lbaas
object graph.
There could be 2 options of preserving API compatibility:
1) preserve it on Neutron level. Currently the root object is the Pool. So
at Pool creation we'll also create underlying container, e.g. loadbalancer
object.
Of course it will be possible to create a Pool for existing loadbalancer
providing its id.

2) preserve compatibility on python-neutronclient level. Client could
combine calls for loadbalancer and pool creation, making it transparent for
users (e.g. user creates a pool, loadbalancer is created b y the client,
not by the Neutron)

I prefer second option and that's why:
- It leaves Neutron API clean. Also it will help to avoid lots of
complications in the code.
IMO just one that point justifies the approach.
- It helps to achieve backward compatibility to cli consumers such as
Horizon.

What do you think?

Thanks,
Eugene.


On Mon, Nov 18, 2013 at 12:30 PM, Aaron Rosen <arosen at nicira.com> wrote:

>
>
>
> On Fri, Nov 15, 2013 at 5:59 AM, Stephen Gran <
> stephen.gran at theguardian.com> wrote:
>
>> On 15/11/13 13:14, Eugene Nikanorov wrote:
>>
>>> Hi folks,
>>>
>>> I've created a brief description of this feature.
>>> You can find it here:
>>> https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance
>>> <https://blueprints.launchpad.net/neutron/+spec/lbaas-service-instance>
>>>
>>>
>>> I would appreciate any comments/ideas about this.
>>>
>>
>> This is great - we're starting to experiment with running an appliance
>> load balancer as an openstack instance.  The only quirk so far is that we
>> need to add new vips to the allowed_addresses list on the neutron port, and
>> the API for doing so doesn't allow for incremental updates, so is a bit
>> racy.
>>
>
> Why do you need incremental updates? Doing a PUT with a list of
> IP(cidr)/mac is not very expensive to the point were we need to create an
> address_pair as a top level resource so you could do what you are doing.
> FWIW, the allowed_address_pair attribute works the same way as the
> fixed_ips attribute on the port.
>
>
>>
>> Cheers,
>> --
>> Stephen Gran
>> Senior Systems Integrator - theguardian.com
>> Please consider the environment before printing this email.
>> ------------------------------------------------------------------
>> Visit theguardian.com
>> On your mobile, download the Guardian iPhone app theguardian.com/iphoneand our iPad edition
>> theguardian.com/iPad   Save up to 33% by subscribing to the Guardian and
>> Observer - choose the papers you want and get full digital access.
>> Visit subscribe.theguardian.com
>>
>> This e-mail and all attachments are confidential and may also
>> be privileged. If you are not the named recipient, please notify
>> the sender and delete the e-mail and all attachments immediately.
>> Do not disclose the contents to another person. You may not use
>> the information for any purpose, or store, or copy, it in any way.
>>
>> Guardian News & Media Limited is not liable for any computer
>> viruses or other material transmitted with or as part of this
>> e-mail. You should employ virus checking software.
>>
>> Guardian News & Media Limited
>>
>> A member of Guardian Media Group plc
>> Registered Office
>> PO Box 68164
>> Kings Place
>> 90 York Way
>> London
>> N1P 2AP
>>
>> Registered in England Number 908396
>>
>> ------------------------------------------------------------
>> --------------
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131118/65a66067/attachment.html>