Hi Eugene! Option #2 sounds good.
A few Qs: I assume we would not need to roll the API version? Have there been any detailed proposals on the 'loadbalancer' CRUD operations? In particular, the ability to attach multiple VIPs as was discussed in Hong Kong. In general, I think the loadbalancer container is a good data model change and will help to make the API easier to use. Peter. From: Eugene Nikanorov [mailto:[email protected]] Sent: Monday, November 18, 2013 1:20 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Loadbalancer instance design. 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 <[email protected]<mailto:[email protected]>> wrote: On Fri, Nov 15, 2013 at 5:59 AM, Stephen Gran <[email protected]<mailto:[email protected]>> 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<http://theguardian.com> Please consider the environment before printing this email. ------------------------------------------------------------------ Visit theguardian.com<http://theguardian.com> On your mobile, download the Guardian iPhone app theguardian.com/iphone<http://theguardian.com/iphone> and our iPad edition theguardian.com/iPad<http://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<http://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 [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
