← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1445255] Re: DVR FloatingIP to unbound allowed_address_pairs does not work

 

Reviewed:  https://review.openstack.org/254439
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=6185a09d130edb7a21e21a354b3fa12fcbebe8a6
Submitter: Jenkins
Branch:    master

commit 6185a09d130edb7a21e21a354b3fa12fcbebe8a6
Author: Swaminathan Vasudevan <swaminathan.vasudevan@xxxxxxx>
Date:   Fri Dec 4 16:44:44 2015 -0800

    DVR: Handle unbound allowed_address_pair port with FIP
    
    If an allowed_address_pair port associated with a FloatingIP
    is configured to a service_port, the allowed_address_pair port
    should inherit the service_ports host binding and device
    owner if device_owner is not configured.
    
    Hence the DVR will be able to deploy the FloatingIP for
    the provided allowed_address_pair.
    
    In this case if the associated port's admin state changes,
    the allowed_address_pairs device_owner and host binding will
    be reverted back to None.
    
    When associated service port is deleted the allowed_address_
    pairs device_owner and host binding will be reverted as well.
    
    Change-Id: I32b8d3e85a8e12fc146c419766596fcfb61f32f6
    Closes-Bug: #1445255


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1445255

Title:
  DVR FloatingIP to unbound allowed_address_pairs does not work

Status in neutron:
  Fix Released

Bug description:
  I was trying to follow Aaron's guide here: http://blog.aaronorosen.com
  /implementing-high-availability-instances-with-neutron-using-vrrp/

  VRRP is working fine, but with DVR enabled there is no way to get a
  floatingIP address working with a vIP.

  There has been a discussion about this on #openstack-neutron on the
  16th of April 2015:

  [23:49:26]  <kevinbenton>	dguerri was trying to follow Aaron's guide here: http://blog.aaronorosen.com/implementing-high-availability-instances-with-neutron-using-vrrp/
  [23:49:35]  <kevinbenton>	and it doesn't work with DVR
  [23:50:49]  <armax>	kevinbenton: ok, but are we sure that’s because of an unbound port?
  [23:51:37]  <kevinbenton>	armax: seems to be
  [23:51:56]  <kevinbenton>	armax: no l3 agent will respond to an ARP request for the floating IP when i try it
  [23:52:57]  <armax>	kevinbenton: ok, now I am with you
  [23:53:53]  <armax>	kevinbenton: in aaron’s case the fip is associated to an unbound port
  [23:54:05]  <armax>	kevinbenton: and yet routing works fine
  [23:55:18]  <armax>	kevinbenton: I don’t think taht for such scenario DVR makes much sense
  [23:55:48]  <armax>	kevinbenton: because if we allowed to have teh FIP namespace to land on the dvr_snat agent
  [23:56:02]  <armax>	kevinbenton: you’re basically back to central routing
  [23:56:07]  <kevinbenton>	armax: right
  [23:56:11]  <armax>	kevinbenton: am I making any sense?
  [23:56:29]  <armax>	kevinbenton: I am not saying that lack of VRRP support is nice
  [23:56:37]  <armax>	kevinbenton: I am tryign to wrap my head around this
  [23:56:49]  <kevinbenton>	armax: i was thinking maybe there was some fallback logic where the SNAT one would host a floating IP if there wasn't another l3 agent that could handle it
  [23:57:16]  <kevinbenton>	armax: for example if one of the compute nodes wasn't running the l3 agent
  [23:57:35]  <kevinbenton>	armax: it would be the same scenario
  [23:57:37]  <kevinbenton>	armax: right?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1445255/+subscriptions


References