nova-manage create network does not use network specified on command line

Asked by Chris Blumentritt

This is similar to https://bugs.launchpad.net/nova/+bug/740810

I have troubleshooting also at http://paste.openstack.org/show/1842/

It seems that when I enter the following command:

nova-manage network create 10.0.1.64/27 1 10

It thinks the cidr is 0.0.0.1/24

root@d64-controller:~# cat /var/log/nova/nova-manage.log
2011-07-05 14:45:01,618 DEBUG nova.utils [-] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/pymodules/python2.6/nova/db/sqlalchemy/api.pyc'> from (pid=6800) __get_backend /usr/lib/pymodules/python2.6/nova/utils.py:417
2011-07-05 14:45:02,280 CRITICAL nova [-] index out range for address range size

mysql> select * from networks\G
*************************** 1. row ***************************
         created_at: 2011-07-05 19:45:01
         updated_at: NULL
         deleted_at: NULL
            deleted: 0
                 id: 1
           injected: 0
               cidr: 0.0.0.1/24
            netmask: 255.255.255.0
             bridge: xenbr0
            gateway: 0.0.0.1
          broadcast: 0.0.0.255
                dns: 8.8.4.4
               vlan: NULL
 vpn_public_address: NULL
    vpn_public_port: NULL
vpn_private_address: NULL
         dhcp_start: 0.0.0.2
         project_id: NULL
               host: NULL
            cidr_v6: NULL
         gateway_v6: NULL
              label: 10.0.1.64/27_0
         netmask_v6: NULL
   bridge_interface: NULL
1 row in set (0.01 sec)

mysql> select * from fixed_ips limit 3\G
*************************** 1. row ***************************
          created_at: 2011-07-05 19:45:01
          updated_at: NULL
          deleted_at: NULL
             deleted: 0
                  id: 1
             address: 0.0.0.0
          network_id: 1
         instance_id: NULL
           allocated: 0
              leased: 0
            reserved: 1
virtual_interface_id: NULL
*************************** 2. row ***************************
          created_at: 2011-07-05 19:45:01
          updated_at: NULL
          deleted_at: NULL
             deleted: 0
                  id: 2
             address: 0.0.0.1
          network_id: 1
         instance_id: NULL
           allocated: 0
              leased: 0
            reserved: 1
virtual_interface_id: NULL
*************************** 3. row ***************************
          created_at: 2011-07-05 19:45:01
          updated_at: NULL
          deleted_at: NULL
             deleted: 0
                  id: 3
             address: 0.0.0.2
          network_id: 1
         instance_id: NULL
           allocated: 0
              leased: 0
            reserved: 0
virtual_interface_id: NULL
3 rows in set (0.00 sec)

From nova-manage.log:
2011-07-05 14:45:01,618 DEBUG nova.utils [-] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/pymodules/python2.6/nova/db/sqlalchemy/api.pyc'> from (pid=6800) __get_backend /usr/lib/pymodules/python2.6/nova/utils.py:417
2011-07-05 14:45:02,280 CRITICAL nova [-] index out range for address range size!
(nova): TRACE: Traceback (most recent call last):
(nova): TRACE: File "/usr/bin/nova-manage", line 1276, in <module>
(nova): TRACE: main()
(nova): TRACE: File "/usr/bin/nova-manage", line 1265, in main
(nova): TRACE: fn(*argv)
(nova): TRACE: File "/usr/bin/nova-manage", line 611, in create
(nova): TRACE: bridge_interface=bridge_interface)
(nova): TRACE: File "/usr/lib/pymodules/python2.6/nova/network/manager.py", line 558, in create_networks
(nova): TRACE: cidr = '%s/%s' % (fixed_net[start], significant_bits)
(nova): TRACE: File "/usr/lib/pymodules/python2.6/netaddr/ip/__init__.py", line 917, in __getitem__
(nova): TRACE: raise IndexError('index out range for address range size!')
(nova): TRACE: IndexError: index out range for address range size!
(nova): TRACE:

Nothing logged in nova-network.log

Nothing logged in nova-api.log

Question information

Language:
English Edit question
Status:
Answered
For:
OpenStack Compute (nova) Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Vish Ishaya (vishvananda) said :
#1

With trunk you need to add a label.

nova-manage network create public 10.0.1.64/27 1 10

Sorry for the confusion caused by the parameters changing.

On Jul 5, 2011, at 1:22 PM, Chris Blumentritt wrote:

> Public bug reported:
>
> This is similar to https://bugs.launchpad.net/nova/+bug/740810
>
> I have troubleshooting also at http://paste.openstack.org/show/1842/
>
> It seems that when I enter the following command:
>
> nova-manage network create 10.0.1.64/27 1 10
>
> It thinks the cidr is 0.0.0.1/24
>
> root@d64-controller:~# cat /var/log/nova/nova-manage.log
> 2011-07-05 14:45:01,618 DEBUG nova.utils [-] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/pymodules/python2.6/nova/db/sqlalchemy/api.pyc'> from (pid=6800) __get_backend /usr/lib/pymodules/python2.6/nova/utils.py:417
> 2011-07-05 14:45:02,280 CRITICAL nova [-] index out range for address range size
>
> mysql> select * from networks\G
> *************************** 1. row ***************************
> created_at: 2011-07-05 19:45:01
> updated_at: NULL
> deleted_at: NULL
> deleted: 0
> id: 1
> injected: 0
> cidr: 0.0.0.1/24
> netmask: 255.255.255.0
> bridge: xenbr0
> gateway: 0.0.0.1
> broadcast: 0.0.0.255
> dns: 8.8.4.4
> vlan: NULL
> vpn_public_address: NULL
> vpn_public_port: NULL
> vpn_private_address: NULL
> dhcp_start: 0.0.0.2
> project_id: NULL
> host: NULL
> cidr_v6: NULL
> gateway_v6: NULL
> label: 10.0.1.64/27_0
> netmask_v6: NULL
> bridge_interface: NULL
> 1 row in set (0.01 sec)
>
>
> mysql> select * from fixed_ips limit 3\G
> *************************** 1. row ***************************
> created_at: 2011-07-05 19:45:01
> updated_at: NULL
> deleted_at: NULL
> deleted: 0
> id: 1
> address: 0.0.0.0
> network_id: 1
> instance_id: NULL
> allocated: 0
> leased: 0
> reserved: 1
> virtual_interface_id: NULL
> *************************** 2. row ***************************
> created_at: 2011-07-05 19:45:01
> updated_at: NULL
> deleted_at: NULL
> deleted: 0
> id: 2
> address: 0.0.0.1
> network_id: 1
> instance_id: NULL
> allocated: 0
> leased: 0
> reserved: 1
> virtual_interface_id: NULL
> *************************** 3. row ***************************
> created_at: 2011-07-05 19:45:01
> updated_at: NULL
> deleted_at: NULL
> deleted: 0
> id: 3
> address: 0.0.0.2
> network_id: 1
> instance_id: NULL
> allocated: 0
> leased: 0
> reserved: 0
> virtual_interface_id: NULL
> 3 rows in set (0.00 sec)
>
>
>> From nova-manage.log:
> 2011-07-05 14:45:01,618 DEBUG nova.utils [-] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/pymodules/python2.6/nova/db/sqlalchemy/api.pyc'> from (pid=6800) __get_backend /usr/lib/pymodules/python2.6/nova/utils.py:417
> 2011-07-05 14:45:02,280 CRITICAL nova [-] index out range for address range size!
> (nova): TRACE: Traceback (most recent call last):
> (nova): TRACE: File "/usr/bin/nova-manage", line 1276, in <module>
> (nova): TRACE: main()
> (nova): TRACE: File "/usr/bin/nova-manage", line 1265, in main
> (nova): TRACE: fn(*argv)
> (nova): TRACE: File "/usr/bin/nova-manage", line 611, in create
> (nova): TRACE: bridge_interface=bridge_interface)
> (nova): TRACE: File "/usr/lib/pymodules/python2.6/nova/network/manager.py", line 558, in create_networks
> (nova): TRACE: cidr = '%s/%s' % (fixed_net[start], significant_bits)
> (nova): TRACE: File "/usr/lib/pymodules/python2.6/netaddr/ip/__init__.py", line 917, in __getitem__
> (nova): TRACE: raise IndexError('index out range for address range size!')
> (nova): TRACE: IndexError: index out range for address range size!
> (nova): TRACE:
>
> Nothing logged in nova-network.log
>
> Nothing logged in nova-api.log
>
> ** Affects: nova
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a member of Nova Bug
> Team, which is subscribed to OpenStack Compute (nova).
> https://bugs.launchpad.net/bugs/806168
>
> Title:
> nova-manage create network does not use network specified on command
> line
>
> Status in OpenStack Compute (Nova):
> New
>
> Bug description:
> This is similar to https://bugs.launchpad.net/nova/+bug/740810
>
> I have troubleshooting also at http://paste.openstack.org/show/1842/
>
> It seems that when I enter the following command:
>
> nova-manage network create 10.0.1.64/27 1 10
>
> It thinks the cidr is 0.0.0.1/24
>
> root@d64-controller:~# cat /var/log/nova/nova-manage.log
> 2011-07-05 14:45:01,618 DEBUG nova.utils [-] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/pymodules/python2.6/nova/db/sqlalchemy/api.pyc'> from (pid=6800) __get_backend /usr/lib/pymodules/python2.6/nova/utils.py:417
> 2011-07-05 14:45:02,280 CRITICAL nova [-] index out range for address range size
>
> mysql> select * from networks\G
> *************************** 1. row ***************************
> created_at: 2011-07-05 19:45:01
> updated_at: NULL
> deleted_at: NULL
> deleted: 0
> id: 1
> injected: 0
> cidr: 0.0.0.1/24
> netmask: 255.255.255.0
> bridge: xenbr0
> gateway: 0.0.0.1
> broadcast: 0.0.0.255
> dns: 8.8.4.4
> vlan: NULL
> vpn_public_address: NULL
> vpn_public_port: NULL
> vpn_private_address: NULL
> dhcp_start: 0.0.0.2
> project_id: NULL
> host: NULL
> cidr_v6: NULL
> gateway_v6: NULL
> label: 10.0.1.64/27_0
> netmask_v6: NULL
> bridge_interface: NULL
> 1 row in set (0.01 sec)
>
>
> mysql> select * from fixed_ips limit 3\G
> *************************** 1. row ***************************
> created_at: 2011-07-05 19:45:01
> updated_at: NULL
> deleted_at: NULL
> deleted: 0
> id: 1
> address: 0.0.0.0
> network_id: 1
> instance_id: NULL
> allocated: 0
> leased: 0
> reserved: 1
> virtual_interface_id: NULL
> *************************** 2. row ***************************
> created_at: 2011-07-05 19:45:01
> updated_at: NULL
> deleted_at: NULL
> deleted: 0
> id: 2
> address: 0.0.0.1
> network_id: 1
> instance_id: NULL
> allocated: 0
> leased: 0
> reserved: 1
> virtual_interface_id: NULL
> *************************** 3. row ***************************
> created_at: 2011-07-05 19:45:01
> updated_at: NULL
> deleted_at: NULL
> deleted: 0
> id: 3
> address: 0.0.0.2
> network_id: 1
> instance_id: NULL
> allocated: 0
> leased: 0
> reserved: 0
> virtual_interface_id: NULL
> 3 rows in set (0.00 sec)
>
>
> From nova-manage.log:
> 2011-07-05 14:45:01,618 DEBUG nova.utils [-] backend <module 'nova.db.sqlalchemy.api' from '/usr/lib/pymodules/python2.6/nova/db/sqlalchemy/api.pyc'> from (pid=6800) __get_backend /usr/lib/pymodules/python2.6/nova/utils.py:417
> 2011-07-05 14:45:02,280 CRITICAL nova [-] index out range for address range size!
> (nova): TRACE: Traceback (most recent call last):
> (nova): TRACE: File "/usr/bin/nova-manage", line 1276, in <module>
> (nova): TRACE: main()
> (nova): TRACE: File "/usr/bin/nova-manage", line 1265, in main
> (nova): TRACE: fn(*argv)
> (nova): TRACE: File "/usr/bin/nova-manage", line 611, in create
> (nova): TRACE: bridge_interface=bridge_interface)
> (nova): TRACE: File "/usr/lib/pymodules/python2.6/nova/network/manager.py", line 558, in create_networks
> (nova): TRACE: cidr = '%s/%s' % (fixed_net[start], significant_bits)
> (nova): TRACE: File "/usr/lib/pymodules/python2.6/netaddr/ip/__init__.py", line 917, in __getitem__
> (nova): TRACE: raise IndexError('index out range for address range size!')
> (nova): TRACE: IndexError: index out range for address range size!
> (nova): TRACE:
>
> Nothing logged in nova-network.log
>
> Nothing logged in nova-api.log
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nova/+bug/806168/+subscriptions

Revision history for this message
Thierry Carrez (ttx) said :
#2

From Vish;

With trunk you need to add a label.
nova-manage network create public 10.0.1.64/27 1 10

Revision history for this message
Paul Voccio (pvo) said :
#3

On Aug 25, 2011, at 1:02 PM, Jay Pipes wrote:

> On Wed, Aug 24, 2011 at 10:37 PM, Paul Voccio <email address hidden> wrote:
>> Jay,
>> Thanks for the update. I don't see any phases so far where RSC is involved.
>> How can we help?
>
> OK, eager beaver :) I'm never gonna pass up offers for help!
>

For you, anything. : )

> I think there are two main areas where we could use your help and expertise:
>
> 1) Working with Jim and Monty to ensure that the *actual packages you
> use* are being tested in the continuous deployment system.
>

I had some talks with some of the RSC product folks and there was a slight bit of concern in distributing our actual packages. They are published on the internet, but we're not advertising their location. I know there has been some interest from people outside Rackspace that want to mimic our deployment that we've turned down for now. Mark, I think this is a decision that we may need sooner rather than later.

> Jim Blair is currently working first with Jesse's team on the job
> called openstack-deploy-rax
> (https://jenkins.openstack.org/view/All/job/openstack-deploy-rax/).
> This job kicks off a set of puppet modules that deploy PPA packages
> into a 5-machine lab cluster. The puppet modules are currently broken
> and Andy Smith is working on finding out what the deal is with that.
> Clearly, we want your team to contribute puppet modules that RAX Cloud
> actually uses in deployment, just like Jesse's team is currently
> doing. I will write that action item and responsibility for your team
> into the testing plan. OK with you?

This sounds reasonable. Chris Blumentritt (who works for Ant) has been working closely with the puppet folks on this as well. Looping them in on this so they can plan accordingly.

>
> 2) Writing test cases in the functional test suite that is run against
> clusters deployed in the continuous build system.
>
> This is the piece that Soren will be building out, and I expect him to
> work closely with your team to dramatically increase the functional
> testing coverage of OpenStack. Your team already does a heck of a lot
> of functional testing, but a lot of that testing is done ad-hoc with
> human interaction. Let's turn that human interaction into repeatable
> functional test cases, eh? :) Once Soren has determined what the
> expected output of the test cases should be, I will make sure he works
> with yourself, Matt, and Chris to build out the test cases.
>

Absolutely for this. Gigi -- I imagine this touches a bit of what you are planning to work on as well. Should we coordinate on this point?

> That sound like a decent start?

yay

> -jay

- pvo
This email may include confidential information. If you received it in error, please delete it.

Revision history for this message
Jay Pipes (jaypipes) said :
#4

On Thu, Aug 25, 2011 at 2:15 PM, Paul Voccio <email address hidden> wrote:
> On Aug 25, 2011, at 1:02 PM, Jay Pipes wrote:
>> I think there are two main areas where we could use your help and expertise:
>>
>> 1) Working with Jim and Monty to ensure that the *actual packages you
>> use* are being tested in the continuous deployment system.
>>
> I had some talks with some of the RSC product folks and there was a slight bit of concern in distributing our actual packages. They are published on the internet, but we're not advertising their location. I know there has been some interest from people outside Rackspace that want to mimic our deployment that we've turned down for now. Mark, I think this is a decision that we may need sooner rather than later.

The packages that are tested by the continuous deployment system don't
need to be publically available at all. We can have Jenkins fire a job
on a builder that lives on a private cluster that is identical to your
production environment, and deploy packages from your own private repo
if need be. The key here is that the packages that you are actually
deploying are being built by the continuous deployment system and
deployed on architecture that is identical to your production system.
And those packages are built on each change to any of the core
project's trunks... If you want to collaborate in the public on those
packaging manifests and puppet modules you deploy with, cool beans. If
you don't, you shouldn't feel the need to do so to work with our CI
system.

Cheers!
jay

Revision history for this message
Paul Voccio (pvo) said :
#5

Jay,

This drives a bigger question we've been struggling a bit with. Right now, we had to merge in some multinic work that hadn't landed in trunk yet for our Alpha. The feeling is we won't be able to build packages after each trunk commit automatically due to the merge conflicts that happen. Do you have any thoughts on how we could do this?

There are *general* trunk packages that can be built with XenServer targets, but we won't be running trunk in production. We're likely going to stay a bit behind for sanity reasons.

Would love to hear your thoughts on this.

pvo

On Aug 25, 2011, at 1:21 PM, Jay Pipes wrote:

> On Thu, Aug 25, 2011 at 2:15 PM, Paul Voccio <email address hidden> wrote:
>> On Aug 25, 2011, at 1:02 PM, Jay Pipes wrote:
>>> I think there are two main areas where we could use your help and expertise:
>>>
>>> 1) Working with Jim and Monty to ensure that the *actual packages you
>>> use* are being tested in the continuous deployment system.
>>>
>> I had some talks with some of the RSC product folks and there was a slight bit of concern in distributing our actual packages. They are published on the internet, but we're not advertising their location. I know there has been some interest from people outside Rackspace that want to mimic our deployment that we've turned down for now. Mark, I think this is a decision that we may need sooner rather than later.
>
> The packages that are tested by the continuous deployment system don't
> need to be publically available at all. We can have Jenkins fire a job
> on a builder that lives on a private cluster that is identical to your
> production environment, and deploy packages from your own private repo
> if need be. The key here is that the packages that you are actually
> deploying are being built by the continuous deployment system and
> deployed on architecture that is identical to your production system.
> And those packages are built on each change to any of the core
> project's trunks... If you want to collaborate in the public on those
> packaging manifests and puppet modules you deploy with, cool beans. If
> you don't, you shouldn't feel the need to do so to work with our CI
> system.
>
> Cheers!
> jay

This email may include confidential information. If you received it in error, please delete it.

Can you help with this problem?

Provide an answer of your own, or ask Chris Blumentritt for more information if necessary.

To post a message you must log in.