Hi Stephen, Currently it's not possible. But we're planning to change this in near future. There is a blueprint which supposes change in vip-pool relationship (change it from 1:1 to m:n), as part of it's implementation, unconditional l2 port creation will be removed from loadbalancer_db.py
Here's a blueprint: https://blueprints.launchpad.net/neutron/+spec/lbaas-multiple-vips-per-pool Here's a link to review which removes port creation and moves it into the plugin driver instead: https://review.openstack.org/#/c/41396/ Currently the patch is abandoned until Icehouse, but you can experiment with it. Feel free to ask any further questions. Thanks, Eugene. On Thu, Sep 5, 2013 at 10:13 AM, Stephen Gran <stephen.g...@theguardian.com>wrote: > Hi, > > One of the things I'll be looking at in the near future is writing a > driver for the neutron lbaas service to talk to a bit of hardware we have. > The normal idiom with this hardware is to have a single interface, with > multiple IP addresses attached. It doesn't look like this is currently > possible in the lbaas model - loadbalancer_db.py unconditionally creates a > port. > > What I am hoping to be able to do is create instances within openstack > based on appliance images, give them a neutron port on the right subnet, > and then add secondary IPs as people create loadbalancers. This would also > give us the flexibility to attach security groups to that single port more > easily, but that's a nice side effect. > > Does this sound possible? What would be the best way of achieving this, > given the way things work currently? > > 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 32% 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@lists.openstack.**org <OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev