Ask Your Question

robparrott's profile - activity

2014-07-25 09:53:35 -0500 received badge  Stellar Question (source)
2014-04-24 07:22:24 -0500 received badge  Nice Question (source)
2014-02-18 05:57:56 -0500 received badge  Famous Question (source)
2014-02-18 05:57:56 -0500 received badge  Notable Question (source)
2014-02-02 13:03:57 -0500 received badge  Favorite Question (source)
2014-01-03 09:26:08 -0500 received badge  Famous Question (source)
2013-12-16 08:32:34 -0500 received badge  Notable Question (source)
2013-12-14 21:53:16 -0500 received badge  Taxonomist
2013-12-13 14:40:56 -0500 received badge  Popular Question (source)
2013-12-12 04:54:16 -0500 received badge  Good Answer (source)
2013-12-08 00:01:17 -0500 received badge  Editor (source)
2013-12-07 23:59:04 -0500 asked a question Port on router to public gateway always down.

I've seen this question asked a couple times but none of the responses appear to fit.

I'm seeing the behavior that no matter what I do, the port on a basic router to the public network remains down. This setup is Neutron/Havana with OpenVSwitch+GRE on CentOS/RHEL 6.5. I've been able to see L2 and L3 routing working from VMs, just not outward connectivity due to this issue (the gateway port remains down).

The router in question is as follows:

+--------------------------------------+------+-------------------+------------------------------------------------------------------------------------+
| id                                   | name | mac_address       | fixed_ips                                                                          |
+--------------------------------------+------+-------------------+------------------------------------------------------------------------------------+
| 3ff39a23-4205-4c43-ab7e-9503354a30f3 |      | fa:16:3e:cd:9d:8e | {"subnet_id": "0381e5dd-a3ec-4ab1-aa9e-801706f02966", "ip_address": "10.255.73.2"} |
| 81269f0d-a704-4cc9-871e-ff3cd1774f96 |      | fa:16:3e:3a:e8:5c | {"subnet_id": "3297725c-5def-45f1-a4cb-b3931bd0d9ea", "ip_address": "10.0.1.1"}    |
| 87ddff08-a365-4285-b8ea-d176a180f7e8 |      | fa:16:3e:7d:d1:46 | {"subnet_id": "9e16cce1-dc78-4206-a195-d589f319e4b4", "ip_address": "10.0.0.1"}    |
+--------------------------------------+------+-------------------+------------------------------------------------------------------------------------+

with the problematic network (10.255.73.0/24) attached as a gateway on port:

+-----------------------+------------------------------------------------------------------------------------+
| Field                 | Value                                                                              |
+-----------------------+------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                               |
| allowed_address_pairs |                                                                                    |
| binding:capabilities  | {"port_filter": true}                                                              |
| binding:host_id       | ospoc4.lab.xxx                                                        |
| binding:vif_type      | ovs                                                                                |
| device_id             | 38eea523-ca75-4410-9a28-d0686a2173fe                                               |
| device_owner          | network:router_gateway                                                             |
| extra_dhcp_opts       |                                                                                    |
| fixed_ips             | {"subnet_id": "0381e5dd-a3ec-4ab1-aa9e-801706f02966", "ip_address": "10.255.73.2"} |
| id                    | 3ff39a23-4205-4c43-ab7e-9503354a30f3                                               |
| mac_address           | fa:16:3e:cd:9d:8e                                                                  |
| name                  |                                                                                    |
| network_id            | 715c189b-c79d-4abf-876d-a8cba83b41de                                               |
| security_groups       |                                                                                    |
| status                | DOWN                                                                               |
| tenant_id             |                                                                                    |
+-----------------------+------------------------------------------------------------------------------------+

The problem seems to be with the "ip" command calls to the created interface, in this case named "qg-3ff39a23-42".

The logs (secure and openvswitch) show that the new interface was successfully added to the "br-ex" bridge, but certain commands fail to find the device. The commands called (wrapped by neutron-rootwrap) are as follows:

ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip -o link show qg-3ff39a23-42 
ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip -o link show qg-3ff39a23-42 

ovs-vsctl -- --may-exist add-port br-ex qg-3ff39a23-42 -- set Interface qg-3ff39a23-42 type=internal \
      -- set Interface qg-3ff39a23-42 external-ids:iface-id=3ff39a23-4205-4c43-ab7e-9503354a30f3 \
      -- set Interface qg-3ff39a23-42 external-ids:iface-status=active \
      -- set Interface qg-3ff39a23-42 external-ids:attached-mac=fa:16:3e:cd:9d:8e

ip link set qg-3ff39a23-42 address fa:16:3e:cd:9d:8e 
ip link set qg-3ff39a23-42 netns qrouter-38eea523-ca75-4410-9a28-d0686a2173fe

ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip link set qg-3ff39a23-42 up 
ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip addr show qg-3ff39a23-42 \
      permanent scope global 
ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip -4 addr add 10.255.73.2/24 brd \
      10.255.73.255 scope global dev qg-3ff39a23-42 
ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe arping -A -U \
      -I qg-3ff39a23-42 -c 3 10.255.73.2

Most of the commands succeed, except for the two ip link set ... commands which return

Cannot find device "qg-3ff39a23-42"

At first glance, this looks like a resolution failure since the commands aren't namespaced properly. This OS supports namespaces:

# ip -o netns list
qrouter-38eea523-ca75-4410-9a28-d0686a2173fe

The other ip commands seem to find the device properly. For example, the ip netns exec qrouter-38eea523-ca75-4410-9a28-d0686a2173fe ip -o link show qg-3ff39a23-42 command returns:

21: qg-3ff39a23-42: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN \    link/ether fa:16:3e:cd:9d:8e brd ff:ff:ff:ff:ff:ff

Though it doesn't report being in state UP, instead is in state UNKNOWN.

The gateway port seems to be on the right bridge, since ovs-vsctl show reports

Bridge br-ex
    Port br-ex
        Interface br-ex ...
(more)
2013-11-26 10:05:29 -0500 answered a question How can I get glance image-create with http-image to work behind a proxy?

OK, I've done some debugging, and the hanging behavior occurs at this line:

It seems that we need to figure out how to get httplib to work nicely in order to resolve this ...

2013-11-26 10:04:14 -0500 received badge  Popular Question (source)
2013-11-24 19:27:37 -0500 received badge  Student (source)
2013-11-22 19:44:37 -0500 asked a question How can I get glance image-create with http-image to work behind a proxy?

We have an openstack installation that sits behind a proxy server, and I'm finding that glance image-create fails when the image is specified using --location. Actually, the command hangs for a significant time, then fails.

Has anyone encountered this? How can I specify a proxy for the glance service to use to avoid this?

Thanks in advance.

2013-07-19 09:48:17 -0500 received badge  Famous Question (source)
2013-06-23 05:03:48 -0500 received badge  Nice Answer (source)
2013-06-23 05:03:27 -0500 received badge  Notable Question (source)
2013-06-23 05:03:27 -0500 received badge  Popular Question (source)
2013-05-15 20:47:08 -0500 received badge  Self-Learner (source)
2013-05-15 20:47:08 -0500 received badge  Teacher (source)
2013-05-14 10:00:43 -0500 answered a question Issue when running tempest: AttributeError

FWIW, this was due to an old version of nosetests, which didn't include the "attrib.py" module. It may be useful for the tempest folks to make the version requirements more explicit.

2013-05-13 16:21:37 -0500 asked a question Issue when running tempest: AttributeError

Hi Folks,

I'm working on a reproducible build for Grizzly, and want to run a set of tempest tests at the end of the build process. I'm pulling the grizzly branch of tempest from GitHub, and configure tempest.conf. When I run a set of tests, some work, but then I get failures which seem to be related to python and the nose, and not OpenStack. Here's an example error:

======================================================================
ERROR: Failure: AttributeError ('module' object has no attribute 'attr')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/nose/loader.py", line 364, in loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.6/site-packages/nose/importer.py", line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.6/site-packages/nose/importer.py", line 84, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/tmp/tempest/tempest/tests/identity/admin/test_tenants.py", line 24, in <module>
    class TenantsTestJSON(base.BaseIdentityAdminTest):
  File "/tmp/tempest/tempest/tests/identity/admin/test_tenants.py", line 61, in TenantsTestJSON
    @attr(type='negative')
  File "/tmp/tempest/tempest/test.py", line 46, in decorator
    return nose.plugins.attrib.attr(*args, **kwargs)(f)
AttributeError: 'module' object has no attribute 'attr'

From poking around in the code, this seems to occur for all tests that are decorated with

@attr(type='negative')

and occurs on the "else: return ..." in this decorator function:

def attr(*args, **kwargs):

    def decorator(f):
        testtool_attributes = ('smoke')

        if 'type' in kwargs and kwargs['type'] in testtool_attributes:
            return nose.plugins.attrib.attr(*args, **kwargs)(
                testtools.testcase.attr(kwargs['type'])(f))
        else:
            return nose.plugins.attrib.attr(*args, **kwargs)(f)

    return decorator

However, some tests that are decorated with @attr(typr='smoke') appear to work OK.

Can anyone provide a hint on what I'm missing here?

System is CentOS 6.4 using RDO packages. Python is 2.6 and nose is python-nose-0.10.4-3.1.el6.noarch