yahoo-eng-team team mailing list archive

[Joe Gordon <1037750@xxxxxxxxxxxxxxxxxx>]

no response, closing the bug.

** Changed in: nova
       Status: Incomplete => Invalid

** Changed in: nova
       Status: Invalid => Opinion

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1037750

Title:
  --flat_network_dhcp_start argument is being ignored

Status in OpenStack Compute (Nova):
  Opinion

Bug description:
  My first bug report, so please be kind in case this isn't actually a
  bug.  (I tried searching and also talking to the #openstack channel
  before submitting this.)

  I'm running Ubuntu Server 12.04 along with OpenStack (see version of
  packages at the bottom).

  I have Nova configured to use Flat DHCP networking in Nova.conf:

  # network specific settings
  --network_manager=nova.network.manager.FlatDHCPManager
  --public_interface=eth0
  --flat_interface=eth1
  --flat_network_bridge=br100
  --fixed_range=10.0.118.128/27
  --network_size=32
  --flat_network_dhcp_start=10.0.118.132
  --flat_injected=False
  --force_dhcp_release

  br0 is coming up as 10.0.118.129
  10.0.118.130 is not supposed to be used (I wanted to reserve it)
  eth1 on the controller is getting interface IP 10.0.118.131.  
  So, I want DHCP to start at 10.0.118.132.

  First problem: OpenStack is ignoring that --flat_network_dhcp_start
  argument.  The first IP it handed out was .130.  The second IP it
  handed out was .131.

  Second problem:  When OpenStack handed out .131, it crashed the
  routing on the cloud controller to where the VMs would not route any
  longer through the public interface (eth0) via the bridge (br100,
  .118.29).  Even after terminating the VM with the .131 IP address, it
  required a reboot of the cloud controller to fix the routing issue.

  It would be nice if the --flat_network_dhcp_start would work properly.
  In absence of that, could it be possible to manage the private IP
  addresses in the same way the floating public IPs are managed (i.e. do
  something like a "nova-manage privateip delete xx.xx.xx.xx")

  According to a discussion in #openstack, a workaround for this is to
  update the fixed_ips table in the nova database to manually set
  reserved=1 for the IP Address.  However, that involves directly
  modifying the database.

  Thanks!!

  OpenStack versions installed below:

  ii  nova-api                          2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - API frontend
  ii  nova-cert                         2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - certificate management
  ii  nova-common                       2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - common files
  ii  nova-compute                      2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - compute node
  ii  nova-compute-kvm                  2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - compute node (KVM)
  ii  nova-consoleauth                  2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - Console Authenticator
  ii  nova-doc                          2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - documentation
  ii  nova-network                      2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - Network manager
  ii  nova-objectstore                  2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - object store
  ii  nova-scheduler                    2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - virtual machine scheduler
  ii  nova-volume                       2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute - storage
  ii  python-nova                       2012.1+stable~20120612-3ee026e-0ubuntu1.2  OpenStack Compute Python libraries
  ii  python-novaclient                 2012.1-0ubuntu1                            client library for OpenStack Compute API

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