Open Stack

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 <enikanorov at 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.gran at 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 at lists.openstack.**org <OpenStack-dev at 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 <oda at valinux.co.jp>