RDO tickets are now tracked in Jira https://issues.redhat.com/projects/RDO/issues/
Bug 1203444 - "private" network created by packstack is not owned by any tenant
Summary: "private" network created by packstack is not owned by any tenant
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RDO
Classification: Community
Component: openstack-packstack
Version: Juno
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: Kilo
Assignee: Martin Magr
QA Contact: Shai Revivo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-18 20:32 UTC by Lars Kellogg-Stedman
Modified: 2016-05-18 10:34 UTC (History)
4 users (show)

Fixed In Version: openstack-packstack-8.0.0-0.7.0rc2
Clone Of:
Environment:
Last Closed: 2016-05-18 10:34:53 UTC
Embargoed:


Attachments (Terms of Use)

Description Lars Kellogg-Stedman 2015-03-18 20:32:29 UTC
Running "packstack --allinone" on Fedora 21 using openstack-packstack-2014.2-0.18.dev1462.gbb05296.fc22.noarch provisions both a "public" floating ip network and a "private" fixed ip network.

The "private" network is created without an owning tenant:

neutron net-show private
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | True                                 |
| id                        | da10615d-6c32-40d7-9d9f-c41b62592d59 |
| name                      | private                              |
| provider:network_type     | vxlan                                |
| provider:physical_network |                                      |
| provider:segmentation_id  | 11                                   |
| router:external           | False                                |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   | 8334e882-ee54-43b2-ad66-479cb9c39139 |
| tenant_id                 |                                      |
+---------------------------+--------------------------------------+

This makes it unavailable to the "demo" user.

There are no errors in *_provision_demo.pp.log:
Notice: Compiled catalog for rdo-f21.novalocal in environment production in 0.32 seconds
Notice: /Stage[main]/Main/Firewall[000 forward in]/ensure: created
Notice: /Stage[main]/Main/Firewall[000 nat]/ensure: created
Notice: /Stage[main]/Main/Firewall[000 forward out]/ensure: created
Notice: /Stage[main]/Main/Neutron_network[public]/ensure: created
Notice: /Stage[main]/Main/Neutron_subnet[public_subnet]/ensure: created
Notice: /Stage[main]/Main/Neutron_l3_ovs_bridge[br-ex]/ensure: created
Notice: /Stage[main]/Main/Keystone_tenant[demo]/ensure: created
Notice: /Stage[main]/Main/Neutron_router[router1]/ensure: created
Notice: /Stage[main]/Main/Neutron_network[private]/ensure: created
Notice: /Stage[main]/Main/Neutron_subnet[private_subnet]/ensure: created
Notice: /Stage[main]/Main/Neutron_router_interface[router1:private_subnet]/ensure: created
Notice: /Stage[main]/Main/Keystone_user[demo]/ensure: created
Notice: Finished catalog run in 23.98 seconds

What's odd is that if I run the following manifest by hand:

$tenant_name               = 'demo'
$private_network_name      = 'net0'
$private_subnet_name       = 'net0_subnet'
$fixed_range               = '10.0.0.0/24'

neutron_network { $private_network_name:
ensure      => present,
tenant_name => $tenant_name,
}
neutron_subnet { $private_subnet_name:
ensure       => present,
cidr         => $fixed_range,
network_name => $private_network_name,
tenant_name  => $tenant_name,
}


I end up with a network that is properly assigned to a tenant:

# neutron net-show net0
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | True                                 |
| id                        | 3a2fcfe2-132d-4055-b763-11c72afaa472 |
| name                      | net0                                 |
| provider:network_type     | vxlan                                |
| provider:physical_network |                                      |
| provider:segmentation_id  | 12                                   |
| router:external           | False                                |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   | e1115a89-1705-4882-9e26-56ecf47f3b8f |
| tenant_id                 | ebedccecf13f44578d3cf1368dc272f2     |
+---------------------------+--------------------------------------+

Comment 1 Lars Kellogg-Stedman 2015-03-18 20:38:42 UTC
Possibly related, the "private_subnet" that is created is assigned to the *services* tenant:

# neutron subnet-show private_subnet
+-------------------+--------------------------------------------+
| Field             | Value                                      |
+-------------------+--------------------------------------------+
| allocation_pools  | {"start": "10.0.0.2", "end": "10.0.0.254"} |
| cidr              | 10.0.0.0/24                                |
| dns_nameservers   |                                            |
| enable_dhcp       | True                                       |
| gateway_ip        | 10.0.0.1                                   |
| host_routes       |                                            |
| id                | 8334e882-ee54-43b2-ad66-479cb9c39139       |
| ip_version        | 4                                          |
| ipv6_address_mode |                                            |
| ipv6_ra_mode      |                                            |
| name              | private_subnet                             |
| network_id        | da10615d-6c32-40d7-9d9f-c41b62592d59       |
| tenant_id         | bd5a06ab31bb4ba29e22f9a65d9d6b28           |
+-------------------+--------------------------------------------+

# keystone tenant-list
+----------------------------------+----------+---------+
|                id                |   name   | enabled |
+----------------------------------+----------+---------+
| 83f6c4646e2148e39f3aa3b732ff08a7 |  admin   |   True  |
| ebedccecf13f44578d3cf1368dc272f2 |   demo   |   True  |
| bd5a06ab31bb4ba29e22f9a65d9d6b28 | services |   True  |
+----------------------------------+----------+---------+

Comment 4 Javier Peña 2016-05-18 10:34:53 UTC
This works fine in Mitaka (private network is assigned to demo tenant), so closing.


Note You need to log in before you can comment on or make changes to this bug.