← Back to team overview

yahoo-eng-team team mailing list archive

  1. yahoo-eng-team team
  2. Mailing list archive
  3. Message #08466

[Bug 1271333] [NEW] "nova boot" permits admin user to boot instances on networks belong to other tenants

  Thread Previous • Date Previous • • Thread Next 
Public bug reported:

I have deployed OpenStack using RedHat's "packstack" tool by running
"packstack --allinone", which results in the following tenants:

    (keystone_admin)# keystone tenant-list
    +----------------------------------+----------+---------+
    |                id                |   name   | enabled |
    +----------------------------------+----------+---------+
    | 6b027a9f4d5e48128a7bca823bdb3d2b |  admin   |   True  |
    | 04981100ee194c9697b6a05c6415f9d5 | alt_demo |   True  |
    | 8639e75e13c742c093746c8e70d5cef8 |   demo   |   True  |
    | 0d4f0baadf914584a70633c35a89a072 | services |   True  |
    +----------------------------------+----------+---------+

There are two networks defined in my environment.  As the admin user, I
can see both of them...

    (keystone_admin)# neutron net-list
    +--------------------------------------+---------+------------------------------------------------------+
    | id                                   | name    | subnets                                              |
    +--------------------------------------+---------+------------------------------------------------------+
    | 9039c750-de15-4358-8a38-5807a7fc5c35 | private | 4930ef6a-b03c-43c5-99a7-e003762bc4be 10.0.0.0/24     |
    | fdf2804f-8fae-4753-9330-484e7e061c1f | public  | fc69c07c-6ff7-4bc5-9984-d1f8e7e55887 172.24.4.224/28 |
    +--------------------------------------+---------+------------------------------------------------------+

...even though the "private" network is owned by the "demo" tenant:

    (keystone_admin)# neutron net-show private
    +---------------------------+--------------------------------------+
    | Field                     | Value                                |
    +---------------------------+--------------------------------------+
    | admin_state_up            | True                                 |
    | id                        | 9039c750-de15-4358-8a38-5807a7fc5c35 |
    | name                      | private                              |
    | provider:network_type     | local                                |
    | provider:physical_network |                                      |
    | provider:segmentation_id  |                                      |
    | router:external           | False                                |
    | shared                    | False                                |
    | status                    | ACTIVE                               |
    | subnets                   | 4930ef6a-b03c-43c5-99a7-e003762bc4be |
    | tenant_id                 | 8639e75e13c742c093746c8e70d5cef8     |
    +---------------------------+--------------------------------------+

Because this network is visible to admin, I can do this:

    nova boot ... --nic net-id=8639e75e13c742c093746c8e70d5cef8 test0

Which works great...until I reboot.  At this point, attempts to
interact with the instance (e.g., using "nova reboot") result in the
following exception:

     File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 1029, in _build_network_info_model
       subnets)
     File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 959, in _nw_info_build_network
       label=network_name,
    UnboundLocalError: local variable 'network_name' referenced before assignment

This happens because in nova/network/neutronv2/api.py, in
API._get_available_networks(), there is this:

    search_opts = {'tenant_id': project_id, 'shared': False}
    nets = neutron.list_networks(**search_opts).get('networks', [])

Here, nova is explicitly filtering on project_id, which means that
networks that do not belong to the admin tenant will not be
discovered.  In _nw_info_build_network(), this causes problems in the
initial loop:

    def _nw_info_build_network(self, port, networks, subnets):
        # NOTE(danms): This loop can't fail to find a network since we
        # filtered ports to only the ones matching networks in our parent
        for net in networks:
            if port['network_id'] == net['id']:
                network_name = net['name']
                break

Because port['network_id'] = '9039c750-de15-4358-8a38-5807a7fc5c35',
but that network was never discovered in _get_available_networks, this
loops exits without setting network_name, causing the above exception.

I think that the initial "nova boot" command should have failed, but
also that this situation ought to be recoverable (currently, because
of this error, the instance is effectively unmaintainable -- it can be
neither rebooted nor deleted).

** Affects: nova
     Importance: Undecided
         Status: New

-- 
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/1271333

Title:
  "nova boot" permits admin user to boot instances on networks belong to
  other tenants

Status in OpenStack Compute (Nova):
  New

Bug description:
  I have deployed OpenStack using RedHat's "packstack" tool by running
  "packstack --allinone", which results in the following tenants:

      (keystone_admin)# keystone tenant-list
      +----------------------------------+----------+---------+
      |                id                |   name   | enabled |
      +----------------------------------+----------+---------+
      | 6b027a9f4d5e48128a7bca823bdb3d2b |  admin   |   True  |
      | 04981100ee194c9697b6a05c6415f9d5 | alt_demo |   True  |
      | 8639e75e13c742c093746c8e70d5cef8 |   demo   |   True  |
      | 0d4f0baadf914584a70633c35a89a072 | services |   True  |
      +----------------------------------+----------+---------+

  There are two networks defined in my environment.  As the admin user,
  I can see both of them...

      (keystone_admin)# neutron net-list
      +--------------------------------------+---------+------------------------------------------------------+
      | id                                   | name    | subnets                                              |
      +--------------------------------------+---------+------------------------------------------------------+
      | 9039c750-de15-4358-8a38-5807a7fc5c35 | private | 4930ef6a-b03c-43c5-99a7-e003762bc4be 10.0.0.0/24     |
      | fdf2804f-8fae-4753-9330-484e7e061c1f | public  | fc69c07c-6ff7-4bc5-9984-d1f8e7e55887 172.24.4.224/28 |
      +--------------------------------------+---------+------------------------------------------------------+

  ...even though the "private" network is owned by the "demo" tenant:

      (keystone_admin)# neutron net-show private
      +---------------------------+--------------------------------------+
      | Field                     | Value                                |
      +---------------------------+--------------------------------------+
      | admin_state_up            | True                                 |
      | id                        | 9039c750-de15-4358-8a38-5807a7fc5c35 |
      | name                      | private                              |
      | provider:network_type     | local                                |
      | provider:physical_network |                                      |
      | provider:segmentation_id  |                                      |
      | router:external           | False                                |
      | shared                    | False                                |
      | status                    | ACTIVE                               |
      | subnets                   | 4930ef6a-b03c-43c5-99a7-e003762bc4be |
      | tenant_id                 | 8639e75e13c742c093746c8e70d5cef8     |
      +---------------------------+--------------------------------------+

  Because this network is visible to admin, I can do this:

      nova boot ... --nic net-id=8639e75e13c742c093746c8e70d5cef8 test0

  Which works great...until I reboot.  At this point, attempts to
  interact with the instance (e.g., using "nova reboot") result in the
  following exception:

       File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 1029, in _build_network_info_model
         subnets)
       File "/usr/lib/python2.6/site-packages/nova/network/neutronv2/api.py", line 959, in _nw_info_build_network
         label=network_name,
      UnboundLocalError: local variable 'network_name' referenced before assignment

  This happens because in nova/network/neutronv2/api.py, in
  API._get_available_networks(), there is this:

      search_opts = {'tenant_id': project_id, 'shared': False}
      nets = neutron.list_networks(**search_opts).get('networks', [])

  Here, nova is explicitly filtering on project_id, which means that
  networks that do not belong to the admin tenant will not be
  discovered.  In _nw_info_build_network(), this causes problems in the
  initial loop:

      def _nw_info_build_network(self, port, networks, subnets):
          # NOTE(danms): This loop can't fail to find a network since we
          # filtered ports to only the ones matching networks in our parent
          for net in networks:
              if port['network_id'] == net['id']:
                  network_name = net['name']
                  break

  Because port['network_id'] = '9039c750-de15-4358-8a38-5807a7fc5c35',
  but that network was never discovered in _get_available_networks, this
  loops exits without setting network_name, causing the above exception.

  I think that the initial "nova boot" command should have failed, but
  also that this situation ought to be recoverable (currently, because
  of this error, the instance is effectively unmaintainable -- it can be
  neither rebooted nor deleted).

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

Follow ups

References

  Thread Previous • Date Previous • • Thread Next