Hi, Please consider the following use case make abailable too: ip address/subnet of vips are same but protocol_port are diffrent. This is not able either currently.
Thanks. On Thu, 5 Sep 2013 10:26:36 +0400 Eugene Nikanorov <enikano...@mirantis.com> wrote: > 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> > > -- Itsuro ODA <o...@valinux.co.jp> _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev