<div dir="ltr">I think we can discuss backward compatibility further.<div><br></div><div>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.</div>
<div>There could be 2 options of preserving API compatibility:</div><div>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.</div>
<div>Of course it will be possible to create a Pool for existing loadbalancer providing its id.</div><div><br></div><div>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)</div>
<div><br></div><div>I prefer second option and that's why:</div><div>- It leaves Neutron API clean. Also it will help to avoid lots of complications in the code.</div><div>IMO just one that point justifies the approach.</div>
<div>- It helps to achieve backward compatibility to cli consumers such as Horizon.</div><div><br></div><div>What do you think?</div><div><br></div><div>Thanks,</div><div>Eugene.</div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Mon, Nov 18, 2013 at 12:30 PM, Aaron Rosen <span dir="ltr"><<a href="mailto:arosen@nicira.com" target="_blank">arosen@nicira.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Fri, Nov 15, 2013 at 5:59 AM, Stephen Gran <span dir="ltr"><<a href="mailto:stephen.gran@theguardian.com" target="_blank">stephen.gran@theguardian.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 15/11/13 13:14, Eugene Nikanorov wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Hi folks,<br>
<br>
I've created a brief description of this feature.<br>
You can find it here:<br>
<a href="https://wiki.openstack.org/wiki/Neutron/LBaaS/LoadbalancerInstance" target="_blank">https://wiki.openstack.org/<u></u>wiki/Neutron/LBaaS/<u></u>LoadbalancerInstance</a><br></div>
<<a href="https://blueprints.launchpad.net/neutron/+spec/lbaas-service-instance" target="_blank">https://blueprints.launchpad.<u></u>net/neutron/+spec/lbaas-<u></u>service-instance</a>><div><br>
<br>
I would appreciate any comments/ideas about this.<br>
</div></blockquote>
<br>
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.<br>
</blockquote><div><br></div></div><div>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. </div>
<div><div class="h5">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
-- <br>
Stephen Gran<br>
Senior Systems Integrator - <a href="http://theguardian.com" target="_blank">theguardian.com</a><br>
Please consider the environment before printing this email.<br>
------------------------------<u></u>------------------------------<u></u>------<br>
Visit <a href="http://theguardian.com" target="_blank">theguardian.com</a> <br>
On your mobile, download the Guardian iPhone app <a href="http://theguardian.com/iphone" target="_blank">theguardian.com/iphone</a> and our iPad edition <a href="http://theguardian.com/iPad" target="_blank">theguardian.com/iPad</a> Save up to 33% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access.<br>
Visit <a href="http://subscribe.theguardian.com" target="_blank">subscribe.theguardian.com</a><br>
<br>
This e-mail and all attachments are confidential and may also<br>
be privileged. If you are not the named recipient, please notify<br>
the sender and delete the e-mail and all attachments immediately.<br>
Do not disclose the contents to another person. You may not use<br>
the information for any purpose, or store, or copy, it in any way.<br>
<br>
Guardian News & Media Limited is not liable for any computer<br>
viruses or other material transmitted with or as part of this<br>
e-mail. You should employ virus checking software.<br>
<br>
Guardian News & Media Limited<br>
<br>
A member of Guardian Media Group plc<br>
Registered Office<br>
PO Box 68164<br>
Kings Place<br>
90 York Way<br>
London<br>
N1P 2AP<br>
<br>
Registered in England Number 908396<br>
<br>
------------------------------<u></u>------------------------------<u></u>--------------<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>