Re: [openstack-dev] [Neutron] IPv6 team summit meetup
Hi, guys: Very nice to talk to all of you yesterday. Unfortunately I need to head out to the airport at 1pm, so I won't be able to make it for the lunch. :( Will see you on IRC and keep in touch! Shixiong On Thu, Nov 6, 2014 at 4:18 PM, Xuhan Peng pengxu...@gmail.com wrote: Hey, Since we don't have any slot for ipv6 in summit to meet up, can we have a lunch meetup together tomorrow (11/7 Friday)? We can meet at 12:30 at the meet up place Neuilly lobby of Le Meridien and go to lunch together after that. Xu Han — Sent from Mailbox https://www.dropbox.com/mailbox for iPhone ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Issues on dnsmasq
Hi, Xu Han: You mentioned in the weekly meeting that you guys saw some issues in the lab, which may pertain to the dnsmasq source code I wrote. Would you please share with me the symptom and the procedures to reproduce them? I would like to take a look and fix the issue if necessary. Thanks! Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Minutes from May 27 2014
I am reading the meeting minute, and saw the discussion on this BP submitted by xuhanp: https://review.openstack.org/#/c/76125/ I don’t see any reason why we need it….do you? Shixiong On May 27, 2014, at 12:47 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-27-14.01.html -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Privacy extension
Awesome! Seems like we reached agreement for not covering privacy extension at this moment. I am totally fine with that. To put closure on this subject, do you think we need to document it and provide user with work-around in case somebody asks for it in Juno release? Shixiong On May 16, 2014, at 3:29 PM, Robert Li (baoli) ba...@cisco.com wrote: Dane put some notes on the session??s ether pad to support multiple prefixes. Seem like this is really something that everyone want to support in openstack. ??Robert On 5/16/14, 2:23 PM, Martinx - ?` thiagocmarti...@gmail.com wrote: Precisely Anthony! We talked about this topic (Non-NAT Floating IPv6) here, on the following thread: -- [openstack-dev] [Neutron][IPv6] Idea: Floating IPv6 - Without any kind of NAT: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026871.html -- :-D About IPv6 Privacy Extensions, well, if it is too hard to implement, I think that it can be postponed... And only the IPv6 self-generated by SLAAC and previously calculated by Neutron itself (based on Instance's MAC address), should be allowed to pass/work for now... - Thiago On 16 May 2014 12:12, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: I??ll take this one a step further. I think one of the methods for getting (non-NAT) floating IPs in IPv6 would be to push a new, extra address to the same port. Either by crafting an extra, unicast RA to the specific VM or providing multiple IA_NA fields in the DHCPv6 transaction. This would require multiple addresses to be allowed on a single MAC. -Anthony From: Martinx - ?` thiagocmarti...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, May 15, 2014 at 14:18 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][IPv6] Privacy extension Hello! I agree that there is no need for Privacy Extensions in a Cloud environment, since MAC address are fake... No big deal... Nevertheless, I think that should be nice to allow 1 Instance to have more than 1 IPv6 addr, since IPv6 is (almost) virtually unlimited... This way, a VM with, for example, a range of IPv6s to it, can have a shared host environment when each website have its own IPv6 address (I prefer to use IP-Based virtualhosts on Apache, instead of Name-Based)... Cheers! Thiago On 15 May 2014 14:22, Ian Wells ijw.ubu...@cack.org.uk wrote: I was just about to respond to that in the session when we ran out of time. I would vote for simply insisting that VMs run without the privacy extension enabled, and only permitting the expected ipv6 address based on MAC. Its primary purpose is to conceal your MAC address so that your IP address can't be used to track you, as I understand it, and I don't think that's as relevant in a cloud environment and where the MAC addresses are basically fake. Someone interested in desktop virtualisation with Openstack may wish to contradict me... -- Ian. On 15 May 2014 09:30, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, guys: Nice to meet with all of you in the technical session and design session. I mentioned the challenge of privacy extension in the meeting, but would like to hear your opinions of how to address the problem. If you have any comments or suggestions, please let me know. I will create a BP for this problem. Thanks! Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Privacy extension
Hi, guys: Nice to meet with all of you in the technical session and design session. I mentioned the challenge of privacy extension in the meeting, but would like to hear your opinions of how to address the problem. If you have any comments or suggestions, please let me know. I will create a BP for this problem. Thanks! Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Cannot make it today
Hi, guys: For two weeks in the row, I have customer meeting at 10am EDT, which conflicts with our weekly Neutron IPv6 call. I hope this meeting schedule won’t be permanent…Will try my best to avoid it. Sorry for the absence. :( Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] IRC meeting today?
Do we have IRC meeting today? Didn’t see anybody in the chat room…..:( Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---!___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Reply: [Neutron][IPv6] tox run forever
I started thinking whether passing the test of Mr. Jenkins is a mindless
dreaming….:) What does the “TOX” say? :)
Shixiong
Begin forwarded message:
From: Shixiong Shang sparkofwisdom.cl...@gmail.com
Subject: Re: [openstack-dev] [Neutron] tox run forever
Date: February 27, 2014 at 9:41:34 PM EST
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Hi, Clark:
Thanks a lot for the prompt response! I added the OS_TEST_TIMEOUT value (300
sec) and was tailing the tmp file. It turned out that the TOX run stopped at
the following point. My machine was tossed so badly that it became
unresponsive and I had to hard reboot it….I am pulling my teeth off now…..Is
it normal to see Traceback?
2014-02-27 21:33:51,212 INFO [neutron.api.extensions] Extension 'agent'
provides no backward compatibility map for extended attributes
2014-02-27 21:33:51,212 INFO [neutron.api.extensions] Extension 'Allowed
Address Pairs' provides no backward compatibility map for extended attributes
2014-02-27 21:33:51,212 INFO [neutron.api.extensions] Extension 'Neutron
Extra Route' provides no backward compatibility map for extended attributes
2014-02-27 21:33:51,522ERROR
[neutron.api.rpc.agentnotifiers.dhcp_rpc_agent_api] No DHCP agents are
associated with network '397fab50-26aa-4cb7-8aa4-c4d43909a00b'. Unable to
send notification for 'network_create_end' with payload: {'network':
{'status': 'ACTIVE', 'subnets': [], 'name': 'net1',
'provider:physical_network': u'physnet1', 'admin_state_up': True,
'tenant_id': 'test-tenant', 'provider:network_type': 'vlan', 'shared': False,
'id': '397fab50-26aa-4cb7-8aa4-c4d43909a00b', 'provider:segmentation_id':
1000}}
2014-02-27 21:33:51,567ERROR [neutron.api.v2.resource] create failed
Traceback (most recent call last):
File neutron/api/v2/resource.py, line 84, in resource
result = method(request=request, **args)
File neutron/api/v2/base.py, line 347, in create
allow_bulk=self._allow_bulk)
File neutron/api/v2/base.py, line 600, in prepare_request_body
raise webob.exc.HTTPBadRequest(msg)
HTTPBadRequest: Invalid input for cidr. Reason: '10.0.2.0' isn't a recognized
IP subnet cidr, '10.0.2.0/32' is recommended.
Thanks again!
Shixiong
Shixiong Shang
!--- Stay Hungry, Stay Foolish ---!
On Feb 27, 2014, at 8:28 PM, Clark Boylan clark.boy...@gmail.com wrote:
On Thu, Feb 27, 2014 at 4:43 PM, Shixiong Shang
sparkofwisdom.cl...@gmail.com wrote:
Hi, guys:
I created a fresh local repository and pulled the most recent Neutron code.
Before I put in my own code, I did TOX run. However, seems like it is stuck
to the following condition for over a hour and didn't go any further.
Yesterday, the TOX had been running with a fresh copy of Neutron, but
didn't return SUCCESS after the entire night.
I assume the copy from MASTER BRANCH should already be
sanitized.However, what I saw in the past 48 hours told me different
story. Did I do anything wrong?
shshang@net-ubuntu2:~/github/neutron$ tox -e py27
py27 create: /home/shshang/github/neutron/.tox/py27
py27 installdeps: -r/home/shshang/github/neutron/requirements.txt,
-r/home/shshang/github/neutron/test-requirements.txt, setuptools_git=0.4
py27 develop-inst: /home/shshang/github/neutron
py27 runtests: commands[0] | python -m neutron.openstack.common.lockutils
python setup.py testr --slowest --testr-args=
[pbr] Excluding argparse: Python 2.6 only dependency
running testr
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --list
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpbZwLwg
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmp39qJYM
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpppXiTc
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpPhJZDc
Thanks!
Shixiong
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think there are two potential problems here. Either a test is
deadlocking due to something it has done or
neutron.openstack.common.lockutils is deadlocking. In either case
OS_TEST_TIMEOUT is not set in .testr.conf so the test suite will not
timeout individual tests if necessary. I would start by setting
[openstack-dev] [Nuetron][IPv6]
Hi, guys: What should I do to fix these “tempest” failures? Any suggestions or pointers are highly appreciated! Thanks! Shixiong Jenkins 12:36 AM Patch Set 13: Doesn't seem to work Build failed. For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures gate-neutron-pep8 SUCCESS in 1m 59s gate-neutron-docs SUCCESS in 2m 27s gate-neutron-python26 SUCCESS in 19m 13s gate-neutron-python27 SUCCESS in 13m 04s check-tempest-dsvm-neutron FAILURE in 10m 46s check-tempest-dsvm-neutron-full FAILURE in 11m 20s (non-voting) check-tempest-dsvm-neutron-pg FAILURE in 12m 58s check-tempest-dsvm-neutron-isolated FAILURE in 9m 27s check-tempest-dsvm-neutron-pg-isolated FAILURE in 10m 01s gate-tempest-dsvm-neutron-large-ops FAILURE in 25m 45s check-grenade-dsvm-neutron FAILURE in 25m 49s (non-voting) check-devstack-dsvm-neutron FAILURE in 11m 38s (non-voting) Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][IPv6] Testing functionality of IPv6 modes using Horizon
Hi, Abishek: I tried your code and shot you an email with some questions….Would you please let me know the dependency between your code and Sean’s? W.r.t. to your second question, I cannot recall on top of my head (with exhausted brain) right now which event subnet update will trigger. I need to read the code tomorrow to confirm. If the event can in turn be consumed by dhcp_agent and invoke dnsmasq reload, then we should be good to go. Otherwise, I suggest we postpone it to next major release. For Icehouse, user have to delete the subnet and recreate it if they want to make any change. We can list it as caveat/limitation. Thanks! Shixiong On Feb 28, 2014, at 10:55 AM, Abishek Subramanian (absubram) absub...@cisco.com wrote: Hi, I just wanted to find out if anyone had been able to test using Horizon? Was everything ok? Additionally wanted to confirm - the two modes can be updated too yes when using neutron subnet-update? Thanks! On 2/18/14 12:58 PM, Abishek Subramanian (absubram) absub...@cisco.com wrote: Hi shshang, all, I have some preliminary Horizon diffs available and if anyone would be kind enough to patch them and try to test the functionality, I'd really appreciate it. I know I'm able to create subnets successfully with the two modes but if there's anything else you'd like to test or have any other user experience comments, please feel free to let me know. The diffs are at - https://review.openstack.org/74453 Thanks!! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] tox run forever
Hi, guys:
I created a fresh local repository and pulled the most recent Neutron code.
Before I put in my own code, I did TOX run. However, seems like it is stuck to
the following condition for over a hour and didn’t go any further. Yesterday,
the TOX had been running with a fresh copy of Neutron, but didn’t return
SUCCESS after the entire night.
I assume the copy from MASTER BRANCH should already be sanitized…..However,
what I saw in the past 48 hours told me different story. Did I do anything
wrong?
shshang@net-ubuntu2:~/github/neutron$ tox -e py27
py27 create: /home/shshang/github/neutron/.tox/py27
py27 installdeps: -r/home/shshang/github/neutron/requirements.txt,
-r/home/shshang/github/neutron/test-requirements.txt, setuptools_git=0.4
py27 develop-inst: /home/shshang/github/neutron
py27 runtests: commands[0] | python -m neutron.openstack.common.lockutils
python setup.py testr --slowest --testr-args=
[pbr] Excluding argparse: Python 2.6 only dependency
running testr
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --list
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpbZwLwg
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmp39qJYM
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpppXiTc
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpPhJZDc
Thanks!
Shixiong
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] tox run forever
In case you have filter set up on your mail client……..
Begin forwarded message:
From: Shixiong Shang sparkofwisdom.cl...@gmail.com
Subject: [openstack-dev] [Neutron] tox run forever
Date: February 27, 2014 at 7:43:03 PM EST
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Hi, guys:
I created a fresh local repository and pulled the most recent Neutron code.
Before I put in my own code, I did TOX run. However, seems like it is stuck
to the following condition for over a hour and didn’t go any further.
Yesterday, the TOX had been running with a fresh copy of Neutron, but didn’t
return SUCCESS after the entire night.
I assume the copy from MASTER BRANCH should already be sanitized…..However,
what I saw in the past 48 hours told me different story. Did I do anything
wrong?
shshang@net-ubuntu2:~/github/neutron$ tox -e py27
py27 create: /home/shshang/github/neutron/.tox/py27
py27 installdeps: -r/home/shshang/github/neutron/requirements.txt,
-r/home/shshang/github/neutron/test-requirements.txt, setuptools_git=0.4
py27 develop-inst: /home/shshang/github/neutron
py27 runtests: commands[0] | python -m neutron.openstack.common.lockutils
python setup.py testr --slowest --testr-args=
[pbr] Excluding argparse: Python 2.6 only dependency
running testr
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --list
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpbZwLwg
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmp39qJYM
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpppXiTc
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpPhJZDc
Thanks!
Shixiong
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] tox error
Hi, Randy: Try this command to install pyudev library…. sudo pip install pyudev Let me know whether it works or not. Good luck! Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---! On Feb 27, 2014, at 9:09 PM, Randy Tuttle randy.m.tut...@gmail.com wrote: Clark/Sean/Shixiong... I have the same error, and tried to import neutron.tests.unit.linuxbridge.test_lb_neutron_agent (no error4 prefix). I get the following (py27)rantuttl-mac:bin rtuttle$ python Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type help, copyright, credits or license for more information. import neutron.tests.unit.linuxbridge.test_lb_neutron_agent Traceback (most recent call last): File stdin, line 1, in module File /Users/rtuttle/projects/neutron/neutron/tests/unit/linuxbridge/test_lb_neutron_agent.py, line 29, in module from neutron.plugins.linuxbridge.agent import linuxbridge_neutron_agent File /Users/rtuttle/projects/neutron/neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py, line 33, in module import pyudev ImportError: No module named pyudev Looks like it wants pyudev, which is not anywhere that I can find, and is not in requirements.txt. Code slice. import distutils.version as dist_version import os import platform import sys import time import eventlet from oslo.config import cfg import pyudev from neutron.agent import l2population_rpc as l2pop_rpc from neutron.agent.linux import ip_lib Still digging into it... Randy On Thu, Feb 27, 2014 at 3:10 PM, Clark Boylan clark.boy...@gmail.com wrote: On Thu, Feb 27, 2014 at 11:39 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: Shixiong Shang and I ran into this problem with Tox today while we were pair programming, and I've also seen similar barfs on my DevStack lab boxes - it's quite a mess. Frankly I've moved to using nosetests as a workaround, and have added it to the developer docs. We really do need to figure out how to make Tox and Testr give more useful failure output - it's so huge it makes my iTerm2 window lock up when I try and do an incremental search on the output. Help from a Testr / Tox guru would be appreciated. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev These failures are a result of testr or discover (depending on the step in the test process, discovery happens first) running into python import failures. In the example above it looks like neutron.tests.unit. linuxbridge.test_lb_neutron_agent failed to import. You can spin up a python interpreter and try importing that to debug (note that is what you tried to do but I believe errors4 is part of the error message and not the thing that couldn't be imported). Flake8 may also catch the problem. Lifeless has laid the groundwork to fix this upstream in testtools [0], but I don't think the corresponding testrepository improvements have been released yet. You can however install testrepository from source [1] and see if that solves your problem. Without seeing the code in question it is really hard to debug any further. If nosetests does work that would indicate a possible intertest dependency that nose resolves by running tests in a particular order which is different than the order used by testr. Finally, when using the python executable from a virtualenv you don't want to be in the virtualenv's bin dir. To do a proper import test you want to be in the root dir of the repository `cd ~/github/neutron` the either activate the virtualenv and run python or skip activation and do `.tox/py27/bin/python` to run the virtualenv's python binary. [0] https://github.com/testing-cabal/testtools/commit/6da4893939c6fd2d732bb20a4ac50db2fe639132 [1] https://launchpad.net/testrepository/ Hope this helps, Clark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] tox run forever
Hi, Clark:
Thanks a lot for the prompt response! I added the OS_TEST_TIMEOUT value (300
sec) and was tailing the tmp file. It turned out that the TOX run stopped at
the following point. My machine was tossed so badly that it became unresponsive
and I had to hard reboot it….I am pulling my teeth off now…..Is it normal to
see Traceback?
2014-02-27 21:33:51,212 INFO [neutron.api.extensions] Extension 'agent'
provides no backward compatibility map for extended attributes
2014-02-27 21:33:51,212 INFO [neutron.api.extensions] Extension 'Allowed
Address Pairs' provides no backward compatibility map for extended attributes
2014-02-27 21:33:51,212 INFO [neutron.api.extensions] Extension 'Neutron
Extra Route' provides no backward compatibility map for extended attributes
2014-02-27 21:33:51,522ERROR
[neutron.api.rpc.agentnotifiers.dhcp_rpc_agent_api] No DHCP agents are
associated with network '397fab50-26aa-4cb7-8aa4-c4d43909a00b'. Unable to send
notification for 'network_create_end' with payload: {'network': {'status':
'ACTIVE', 'subnets': [], 'name': 'net1', 'provider:physical_network':
u'physnet1', 'admin_state_up': True, 'tenant_id': 'test-tenant',
'provider:network_type': 'vlan', 'shared': False, 'id':
'397fab50-26aa-4cb7-8aa4-c4d43909a00b', 'provider:segmentation_id': 1000}}
2014-02-27 21:33:51,567ERROR [neutron.api.v2.resource] create failed
Traceback (most recent call last):
File neutron/api/v2/resource.py, line 84, in resource
result = method(request=request, **args)
File neutron/api/v2/base.py, line 347, in create
allow_bulk=self._allow_bulk)
File neutron/api/v2/base.py, line 600, in prepare_request_body
raise webob.exc.HTTPBadRequest(msg)
HTTPBadRequest: Invalid input for cidr. Reason: '10.0.2.0' isn't a recognized
IP subnet cidr, '10.0.2.0/32' is recommended.
Thanks again!
Shixiong
Shixiong Shang
!--- Stay Hungry, Stay Foolish ---!
On Feb 27, 2014, at 8:28 PM, Clark Boylan clark.boy...@gmail.com wrote:
On Thu, Feb 27, 2014 at 4:43 PM, Shixiong Shang
sparkofwisdom.cl...@gmail.com wrote:
Hi, guys:
I created a fresh local repository and pulled the most recent Neutron code.
Before I put in my own code, I did TOX run. However, seems like it is stuck
to the following condition for over a hour and didn't go any further.
Yesterday, the TOX had been running with a fresh copy of Neutron, but didn't
return SUCCESS after the entire night.
I assume the copy from MASTER BRANCH should already be
sanitized.However, what I saw in the past 48 hours told me different
story. Did I do anything wrong?
shshang@net-ubuntu2:~/github/neutron$ tox -e py27
py27 create: /home/shshang/github/neutron/.tox/py27
py27 installdeps: -r/home/shshang/github/neutron/requirements.txt,
-r/home/shshang/github/neutron/test-requirements.txt, setuptools_git=0.4
py27 develop-inst: /home/shshang/github/neutron
py27 runtests: commands[0] | python -m neutron.openstack.common.lockutils
python setup.py testr --slowest --testr-args=
[pbr] Excluding argparse: Python 2.6 only dependency
running testr
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --list
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpbZwLwg
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmp39qJYM
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpppXiTc
running=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_LOG_CAPTURE=1
${PYTHON:-python} -m subunit.run discover -t ./
${OS_TEST_PATH:-./neutron/tests/unit} --load-list /tmp/tmpPhJZDc
Thanks!
Shixiong
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I think there are two potential problems here. Either a test is
deadlocking due to something it has done or
neutron.openstack.common.lockutils is deadlocking. In either case
OS_TEST_TIMEOUT is not set in .testr.conf so the test suite will not
timeout individual tests if necessary. I would start by setting that
in the .testr.conf next to OS_STDOUT_CAPTURE and you probably want a
value of like 300 (that is seconds).
The other thing you can do to debug this is grab the subunit log file
out of .testrepository. While tests are running it will have a tmp
random generated name. After tests have run it will be moved to a file
named after the most recent test run eg 1 for the first run. The
subunit log should offer clues to what was running at the time of
deadlocking
[openstack-dev] [Neutron][IPv6]
Hi, Sean and the team: Do we have a list of code reviews and a list of BPs submitted by Neutron IPv6 sub-team targeting at Icehouse 3? Would appreciate everybody’s help to compose a list so we won’t overlook anything, especially the deadline is next Friday. Thanks! Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] tox error
Hi, guys: I run into this error while running fox…..but it gave me this error…Seems like it is related to Neutron LB. Did you see this issue before? If so, how to fix it? Thanks! Shixiong shshang@net-ubuntu2:~/github/neutron$ tox -v -e py27 ……... tests.unit.test_wsgi.XMLDictSerializerTest.test_xml_with_utf8\xa2\xbe\xf7u\xb3 `@d\x17text/plain;charset=utf8\rimport errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent\x85\xc5\x1a\\', stderr=None error: testr failed (3) ERROR: InvocationError: '/home/shshang/github/neutron/.tox/py27/bin/python -m neutron.openstack.common.lockutils python setup.py testr --slowest --testr-args=' summary ERROR: py27: commands failed (py27)shshang@net-ubuntu2:~/github/neutron/.tox/py27/bin$ python Python 2.7.5+ (default, Sep 19 2013, 13:48:49) [GCC 4.8.1] on linux2 Type help, copyright, credits or license for more information. import errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] tox error (errors4neutron)
Hi, guys: I run into this error while running tox…..Seems like it is related to Neutron LB. Did you see this issue before? If so, how to fix it? Thanks! Shixiong shshang@net-ubuntu2:~/github/neutron$ tox -v -e py27 ……... tests.unit.test_wsgi.XMLDictSerializerTest.test_xml_with_utf8\xa2\xbe\xf7u\xb3 `@d\x17text/plain;charset=utf8\rimport errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent\x85\xc5\x1a\\', stderr=None error: testr failed (3) ERROR: InvocationError: '/home/shshang/github/neutron/.tox/py27/bin/python -m neutron.openstack.common.lockutils python setup.py testr --slowest --testr-args=' summary ERROR: py27: commands failed (py27)shshang@net-ubuntu2:~/github/neutron/.tox/py27/bin$ python Python 2.7.5+ (default, Sep 19 2013, 13:48:49) [GCC 4.8.1] on linux2 Type help, copyright, credits or license for more information. import errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named errors4neutron.tests.unit.linuxbridge.test_lb_neutron_agent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] CLI for the new subnet keywords
Hi, Abishek: Thank you for taking care of Horizon for IPv6 enhancement. So now we have coverage on both CLI and dashboard side. Very exciting! W.r.t your questions, these two parameters work independently. In other words, Horizon should present both options if the interested subnet is IPv6. For each parameter, the valid values are: off slacc dhcpv6-stateful dhcpv6-stateless The CLI command may look like, for example, something below: neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode off NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode dhcpv6-stateful NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode slaac --ipv6_address_mode slaac NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateful --ipv6_address_mode off NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateless --ipv6_address_mode dhcpv6-stateless NETWORK CIDR The valid combinations are outlined in the PDF file below. https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf Please let me know if you have any further questions. Thanks! Shixiong On Feb 10, 2014, at 8:23 PM, Abishek Subramanian (absubram) absub...@cisco.com wrote: Hi IPv6 experts, This is regarding the BP - https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes Is it possible to give me a quick example of the CLI that you envision? This is so that the Horizon BP can be updated accordingly. Once the neutron side of things is ready, when creating a subnet, and the version is IPv6 will now enable these two options, yes? Can both options exist or is it an either/or combination, i.e. either ipv6_ra or ipv6_address? Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
Excellent! Thanks for your confirmation, Sean! On Feb 2, 2014, at 12:53 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Sat, Feb 01, 2014 at 01:18:09AM -0500, Shixiong Shang wrote: In other words, I can retrieve the values by: subnet.ipv6_ra_mode subnet.ipv6_address_mode Is that correct? Would you please confirm? Yes - that is the intent. I just have to fix an issue with the DB column definitions, so that it'll work with postgres, I think I have a closing brace misplaced, so it's not defining the Enum type correctly, and we have to get bug #1270212 resolved, since that's making the unit tests fail. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
I just submitted dnsmasq related code to gerrit: https://review.openstack.org/70649 This submission intended to implement “ipv6-two-attributes” BP and other three blueprints (SLAAC, DHCPv6-Stateful, DHCPv6-Stateless) rooted from it. Please review and let me know what you think. Thanks in advance! Shixiong On Feb 2, 2014, at 12:53 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Sat, Feb 01, 2014 at 01:18:09AM -0500, Shixiong Shang wrote: In other words, I can retrieve the values by: subnet.ipv6_ra_mode subnet.ipv6_address_mode Is that correct? Would you please confirm? Yes - that is the intent. I just have to fix an issue with the DB column definitions, so that it'll work with postgres, I think I have a closing brace misplaced, so it's not defining the Enum type correctly, and we have to get bug #1270212 resolved, since that's making the unit tests fail. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Private or Public network?
Hi, Anthony: Thanks a lot for the quick response! I didn't think about the provider network scenarios. I feel grateful you brought it up. I will add provider network to the chart. Here is my understanding: Private network: VM is attached to a subnet with NO default gateway at all, i.e. completely isolated Provider network: VM is attached to a physical network with a physical router acting as gateway, which is outside of OpenStack’s control From implementation perspective, both cases are identical since Openstack won’t see the gateway port on neutron router. Hence, Openstack should not be responsible to send IPv6 RA. Being said, the code I am developing will perform a check: 1) If an IPv6 subnet does NOT have gateway port on neutron router (i.e. either private or provider network), then only the first two highlighted combinations are considered as valid. Because the rest five options requires RA announcement. 2) If an IPv6 subnet does have gateway port on neutron router (i.e public network), then only the last five highlighted combinations are considered as valid. Because the first two options turn off RA announcement, which makes existing gateway port on neutron router useless. Please keep me honest here……. Thanks again! Shixiong On Feb 1, 2014, at 7:16 PM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: See Inline Hi, guys: While I am implementing the code to support IPv6 two mode keywords, a question came to my mind and I would like to see your opinions. If you look at the table below, you will notice that the first two combinations highlighted with red underline have “ipv6_ra_mode” set to OFF. I think these two options only make sense if the tenant subnet is PRIVATE, i.e. the subnet is not attached to any router. In this case, OpenStack should NOT send RA; On the flip side, if the subset is PUBLIC, i.e. the subnet is attached to a router, then the corresopnding port on the router should be THE default gateway for the tenant subnet, hence, need to handle RA announcement. These options also make sense if you consider the first column of your chart. In both of these cases, they are listed as having an external router. This is REQUIRED for a provider network where the routed is not owned by OpenStack. Please do NOT consider these private-only. In summary, I believe it doesn’t make sense to allow OpenStack to create default gateway for a tenant network, but suppress RA from the default gateway port on Neutron router. If so, the default gateway port is pretty much useless. This is the way I am coding now. However, I might overlook some scenarios. Please chime in if you see any use cases beyond what this table covers. If my upstream router is on-link, then I need to set it as the gateway (for security purposes, we need to be able to filter RAs from rogue agents). However, I still want OpenStack to handle address assignment. Thanks! Shixiong P.S. The PDF file of this table is uploaded to my Dropbox. Here is the link: https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf PastedGraphic-1.png PastedGraphic-1.png___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
Hi, Sean: Thanks a bunch for the new code. I glimpsed it through once and if I understand it correctly, the value of the two parameters are saved as the attributes of a subnet. In other words, I can retrieve the values by: subnet.ipv6_ra_mode subnet.ipv6_address_mode Is that correct? Would you please confirm? Thanks and have a great weekend! Shixiong On Jan 30, 2014, at 6:59 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: I just pushed a new patch that adds the two new attributes to Subnets. https://review.openstack.org/#/c/52983/ It's a very rough draft - but I wanted to get it out the door so people had sufficient time to take a look, so we can discuss at the next IRC meeting. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
Any decisions yet? Shixiong On Jan 23, 2014, at 7:45 AM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: An openstack deployment with an external DHCP server is definetely a possible scenario; I don't think it can be implemented out-of-the-box with the components provided by the core openstack services, but it should be doable and a possibly even a requirement for deployments which integrate openstack with systems such as Infoblox. Therefore I would not disregard the possibility of an external DHCP server. Regarding the new attributes, I pretty much agree on them. As there's overlap between enable_dhcp and address_mode, it might be worth defining a strategy for deprecating enable_dhcp by adding inclduing also a 'dhcpv4' valid value for this attribute. We were initially intending to treat enable_dhcp as an on-off flag for IPv6. If it's off, then we won't even bother with the other two attributes. Because of the issues already being discussed elsewhere in Neutron, you can't assign multiple scopes to a subnet so it's safe to assume that there won't be an IPv4 scope in an IPv6 subnet. Salvatore On 23 January 2014 04:21, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Any possibility we can nail the keywords in the next 12 - 24 hrs? So we can decide the scope in Icehouse release and then, discuss who can do what? Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
Sean, I agree with you. I prefer OpenStack as the single source of truth. What end user chooses may be different. But with this pair of keywords, at least we provide comprehensive coverage on all scenarios. For Icehouse, I suggest we only consider the supports for the scenarios that OpenStack has full control of address assignment, plus one or two scenarios Comcast needs, in order to cover most of the deployments. We can leave other cases for future releases, or professional service opportunities. Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
That is correct, Xu Han! On Jan 22, 2014, at 11:14 AM, Xuhan Peng pengxu...@gmail.com wrote: Ian, I think the last two attributes PDF from Shixiong's last email is trying to solve the problem you are saying, right? — Xu Han Peng (xuhanp) On Wed, Jan 22, 2014 at 8:15 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 21 January 2014 22:46, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: Hi, Sean and Xuhan: I totally agree. This is not the ultimate solution with the assumption that we had to use “enable_dhcp”. We haven’t decided the name of another parameter, however, we are open to any suggestions. As we mentioned during the meeting, the second parameter should highlight the need of addressing. If so, it should have at least four values: 1) off (i.e. address is assigned by external devices out of OpenStack control) 2) slaac (i.e. address is calculated based on RA sent by OpenStack dnsmasq) 3) dhcpv6-stateful (i.e. address is obtained from OpenStack dnsmasq acting as DHCPv6 stateful server) 4) dhcpv6-stateless (i.e. address is calculated based on RA sent from either OpenStack dnsmasq, or external router, and optional information is retrieved from OpenStack dnsmasq acting as DHCPv6 stateless server) So how does this work if I have an external DHCPv6 server and an internal router? (How baroque do we have to get?) enable_dhcp, for backward compatibility reasons, should probably disable *both* RA and DHCPv6, despite the name, so we can't use that to disable the DHCP server. We could add a *third* attribute, which I hate as an idea but does resolve the problem - one flag for each of the servers, one for the mode the servers are operating in, and enable_dhcp which needs to DIAF but will persist till the API is revved. -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
Any possibility we can nail the keywords in the next 12 - 24 hrs? So we can decide the scope in Icehouse release and then, discuss who can do what? Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
Hi, Anthony: I think we are saying the same thing. Yes, there must be two parameters, and they are independent. What I mean of simplifying referred to the CLI. If user provides RA mode, then the 2nd parameter will have default value if user doesn't specify it. However, user can also indicate different value explicitly. The use cases you pointed out are also called out in the table attached to the end of the email. Anything caught your eyes? Thanks, Anthony! Shixiong On Jan 21, 2014, at 4:46 PM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: Hi, Sean and Xuhan: I totally agree. This is not the ultimate solution with the assumption that we had to use “enable_dhcp”. We haven’t decided the name of another parameter, however, we are open to any suggestions. As we mentioned during the meeting, the second parameter should highlight the need of addressing. If so, it should have at least four values: 1) off (i.e. address is assigned by external devices out of OpenStack control) 2) slaac (i.e. address is calculated based on RA sent by OpenStack dnsmasq) 3) dhcpv6-stateful (i.e. address is obtained from OpenStack dnsmasq acting as DHCPv6 stateful server) 4) dhcpv6-stateless (i.e. address is calculated based on RA sent from either OpenStack dnsmasq, or external router, and optional information is retrieved from OpenStack dnsmasq acting as DHCPv6 stateless server) This I agree with. In other words, the original “on” mode captured in “enable_dhcp should provide more granularity. Since the bits in RA will trigger VM to take certain actions (calculate address, solicit DHCPv6, etc.), I think we can simplify it by saying, if OpenStack RA Mode is slacc/dhcpv6-stateful/dhcpv6-stateless, then by default, the 2nd parameters shares the same value. Absolutely not. The reason for separating routing and addressing is because you can't assume that because one piece is present, that the other is too. If I want OpenStack to assign addresses via DHCPv6, then I set the addressing parameter to stateful. But maybe I want the RA to come from my provider network router. In that case, the RA mode is OFF. We MUST separate these, as there are other permutations as well. Thanks! Shixiong PastedGraphic-1.png On Jan 21, 2014, at 10:42 AM, Xuhan Peng pengxu...@gmail.com wrote: I think what will confuse openstack end user/admin will be the difference between the combination of RA mode=slaac, enable_dhcp=off and RA mode=dhcpv6_stateless, enable_dhcp=off. The only difference will be if getting optional info from external DHCPv6 server using DHCPv6 stateless but it's hard to tell from the RA mode unless the admin is very familiar with dnsmasq. I think we are trying to isolate the detail of dnsmasq configuration from the API attribute here based on our previous discussion, but I could not figure out a better mode name here too. Just want to point out this before going to bed. Will be back tomorrow and check on other ones' input on this. On Tue, Jan 21, 2014 at 10:07 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Begin forwarded message: From: Shixiong Shang sparkofwisdom.cl...@gmail.com Subject: Re: Cannot make it today at 4pm EST Date: January 17, 2014 at 3:09:56 PM EST To: Veiga, Anthony anthony_ve...@cable.comcast.com Cc: Ian Wells (iawells) iawe...@cisco.com Hi, Anthony and Ian: Not sure how the API discussion is going with Neutron team. Please let me know what I can help from my side. Last night, I put together this slide to summarize the possible combinations of RA mode and “enable_dhcp” keyword. It is quite clear that the current on/off boolean value won’t be sufficient. However, I think it is still possible to support this pair of keywords within IceHouse timeline while negotiating with Neutron team for more flexible approach in the next major release. If you are thinking along the same line, would you please let me know what I overlooked? Thanks! Shixiong PastedGraphic-1.png On Jan 14, 2014, at 4:47 PM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: OK, I see that we're back to splitting the RA and DHCP modes, though I'm not sure why - enable_dhcp is bugger all use for anything other than a flat-out disable flag, since it's a boolean, so it's not like we can make much use of it. Otherwise are we talking about whether we have an external router and/or DHCP server? Precisely this. We determined multiple times previously that there is a chance of either of these items being external to OpenStack. Where appropriate, we need to also be able to get out of the way. -- Ian. From: Veiga, Anthony anthony_ve...@cable.comcast.com Date: Tuesday, 14 January 2014 21:34 To: Ian Wells iawe...@cisco.com, Shixiong Shang sparkofwisdom.cl...@gmail.com Subject: Re: Cannot make it today
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
I created a new PDF file to show two parameters (i.e. not referring “enable_dhcp”). Here is the link. I also updated BP too. https://www.dropbox.com/s/rq8xmbruqthef38/IPv6%20Two%20Modes%20v2.0.pdf Shixiong On Jan 21, 2014, at 6:31 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, Anthony: I think we are saying the same thing. Yes, there must be two parameters, and they are independent. What I mean of simplifying referred to the CLI. If user provides RA mode, then the 2nd parameter will have default value if user doesn't specify it. However, user can also indicate different value explicitly. The use cases you pointed out are also called out in the table attached to the end of the email. Anything caught your eyes? Thanks, Anthony! Shixiong On Jan 21, 2014, at 4:46 PM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: Hi, Sean and Xuhan: I totally agree. This is not the ultimate solution with the assumption that we had to use “enable_dhcp”. We haven’t decided the name of another parameter, however, we are open to any suggestions. As we mentioned during the meeting, the second parameter should highlight the need of addressing. If so, it should have at least four values: 1) off (i.e. address is assigned by external devices out of OpenStack control) 2) slaac (i.e. address is calculated based on RA sent by OpenStack dnsmasq) 3) dhcpv6-stateful (i.e. address is obtained from OpenStack dnsmasq acting as DHCPv6 stateful server) 4) dhcpv6-stateless (i.e. address is calculated based on RA sent from either OpenStack dnsmasq, or external router, and optional information is retrieved from OpenStack dnsmasq acting as DHCPv6 stateless server) This I agree with. In other words, the original “on” mode captured in “enable_dhcp should provide more granularity. Since the bits in RA will trigger VM to take certain actions (calculate address, solicit DHCPv6, etc.), I think we can simplify it by saying, if OpenStack RA Mode is slacc/dhcpv6-stateful/dhcpv6-stateless, then by default, the 2nd parameters shares the same value. Absolutely not. The reason for separating routing and addressing is because you can't assume that because one piece is present, that the other is too. If I want OpenStack to assign addresses via DHCPv6, then I set the addressing parameter to stateful. But maybe I want the RA to come from my provider network router. In that case, the RA mode is OFF. We MUST separate these, as there are other permutations as well. Thanks! Shixiong PastedGraphic-1.png On Jan 21, 2014, at 10:42 AM, Xuhan Peng pengxu...@gmail.com wrote: I think what will confuse openstack end user/admin will be the difference between the combination of RA mode=slaac, enable_dhcp=off and RA mode=dhcpv6_stateless, enable_dhcp=off. The only difference will be if getting optional info from external DHCPv6 server using DHCPv6 stateless but it's hard to tell from the RA mode unless the admin is very familiar with dnsmasq. I think we are trying to isolate the detail of dnsmasq configuration from the API attribute here based on our previous discussion, but I could not figure out a better mode name here too. Just want to point out this before going to bed. Will be back tomorrow and check on other ones' input on this. On Tue, Jan 21, 2014 at 10:07 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Begin forwarded message: From: Shixiong Shang sparkofwisdom.cl...@gmail.com Subject: Re: Cannot make it today at 4pm EST Date: January 17, 2014 at 3:09:56 PM EST To: Veiga, Anthony anthony_ve...@cable.comcast.com Cc: Ian Wells (iawells) iawe...@cisco.com Hi, Anthony and Ian: Not sure how the API discussion is going with Neutron team. Please let me know what I can help from my side. Last night, I put together this slide to summarize the possible combinations of RA mode and “enable_dhcp” keyword. It is quite clear that the current on/off boolean value won’t be sufficient. However, I think it is still possible to support this pair of keywords within IceHouse timeline while negotiating with Neutron team for more flexible approach in the next major release. If you are thinking along the same line, would you please let me know what I overlooked? Thanks! Shixiong PastedGraphic-1.png On Jan 14, 2014, at 4:47 PM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: OK, I see that we're back to splitting the RA and DHCP modes, though I'm not sure why - enable_dhcp is bugger all use for anything other than a flat-out disable flag, since it's a boolean, so it's not like we can make much use of it. Otherwise are we talking about whether we have an external router and/or DHCP server? Precisely this. We determined multiple times previously that there is a chance of either of these items being
Re: [openstack-dev] [Neutron][IPv6] Several topics for tomorrow's meeting
Hi, Sean: Hope you had a great time with your family and friends during holiday! Tomorrow when we meet in IRC, can we put closure on one pending question on how to pass the “mode” to dnsmasq? If I understand everybody correctly: 1) The mode value should be dnsmasq agnostic 2) The approach should be friendly to both CLI command and Horizon There were a lot of discussion in the last year on this topic, but if I remember correctly, we haven’t reach any agreement yet unless I overlooked some email threads. Another subject in my mind is, can we evaluate the readiness of all blueprints to see which ones can be fulfilled in which timeline? I think we already missed icehouse-1 date…when will be icehouse-2 due? Thanks! Shixiong On Jan 6, 2014, at 12:06 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: I think we've got consensus. See everyone tomorrow at 1500 UTC in #openstack-meeting-alt -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?
Either day works for me. Thanks for setting it up, Sean! On Jan 2, 2014, at 5:08 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: Looking at the calendar, our options for 1500 UTC require us to change the day that we meet. The following days are available: * Tuesdays * Fridays Thoughts? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace
Hi, Xuhan: Thanks for reaching out to us for questions! Here are the summary of several key points: 1. Currently dnsmasq is bound to the ns- interface within qdhcp- namespace. If we continue to use this model, then the announced RA has to use the ns- interface’s link-local address as source, based on standards. 2. When VM receives this RA, it will install default gateway pointing to the ns- interface based on standards. In other words, VM will send packets destined to other subnets to ns- interface. 3. However, outbound traffic should be sent to qr- interface, which is created to act as the default gateway for tenant network. 4. In addition, the qdhcp- namespace has no IPv6 route installed. So traffic will be blackholed. I initially thought about getting rid of entire qdhcp- namespace and only use qrouter namespace. I poked around and nobody could explain to me why we need two separate namespaces. In my opinions, I don’t see the clear value of qdhcp- namespace…... Maybe I overlooked something. But on the second thought, we decided to launch dnsmasq in qrouter- namespace and keep IPv4 dnsmasq in qdhcp- namespace since we didn’t know what else might break. Please let us know if you have any further questions! Thanks! Shixiong On Dec 19, 2013, at 4:05 AM, Xuhan Peng pengxu...@gmail.com wrote: I am reading through the blueprint created by Randy to bind dnsmasq into qrouter- namespace: https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace I don't think I can follow the reason that we need to change the namespace which contains dnsmasq process and the device it listens to from qdhcp- to qrouter-. Why the original namespace design conflicts with the Router Advertisement sending from dnsmasq for SLAAC? From the attached POC result link, the reason is stated as: Even if the dnsmasq process could send Router Advertisement, the default gateway would bind to its own link-local address in the qdhcp- namespace. As a result, traffic leaving tenant network will be drawn to DHCP interface, instead of gateway port on router. That is not desirable! Can Randy or Shixiong explain this more? Thanks! Xuhan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
I will surely be there this afternoon, Sean! Look forward to it! On Dec 19, 2013, at 12:22 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: Perfect! Will you be at the IRC meeting to discuss these? I've added them to the agenda in the hopes that we can discuss -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?
I cannot do 13:00UTC, but 14:00 or 15:00 UTC should work for me. On Dec 19, 2013, at 5:12 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: Thoughts? I know we have people who are not able to attend at our current time. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace
Hi, Ian: The use case brought by Comcast team today during the ipv6 sub-team meeting actually proved the point I made here, instead of against it. If I didn’t explain it clearly in my previous email, here it is. I was questioning the design with two namespaces and I believe we can use a SINGLE namespace as the common container to host two services, i.e. DHCP and ROUTING. If your use case needs DHCP instance, but not ROUTING, then just launch dnsmasq in THE namespace with qr- interface; If your use case needs default GW, then add qg- interface in THE namespace. Whether it is called qdhcp or qrouter, I don’t care. It is just a label. People follow the routine to use it, simply because this is what OpenStack offers. But my question is, why? And why NOT we design the system in the way that qg- and qr- interface collocate in the same namespace? It is because we intentionally separate the service, now the system become clumsy and less efficient. As you can see in IPv6 cases, we are forced to deal with two namespaces now. It just doesn’t make any sense. Shixiong On Dec 19, 2013, at 7:27 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: Per the discussions this evening, we did identify a reason why you might need a dhcp namespace for v6 - because networks don't actually have to have routers. It's clear you need an agent in the router namespace for RAs and another one in the DHCP namespace for when the network's not connected to a router, though. We've not pinned down all the API details yet, but the plan is to implement an RA agent first, responding to subnets that router is attached to (which is very close to what Randy and Shixiong have already done). -- Ian. On 19 December 2013 14:01, Randy Tuttle randy.m.tut...@gmail.com wrote: First, dnsmasq is not being moved. Instead, it's a different instance for the attached subnet in the qrouter namespace. If it's not in the qrouter namespace, the default gateway (the local router interface) will be the interface of qdhcp namespace interface. That will cause blackhole for traffic from VM. As you know, routing tables and NAT all occur in qrouter namespace. So we want the RA to contain the local interface as default gateway in qrouter namespace Randy Sent from my iPhone On Dec 19, 2013, at 4:05 AM, Xuhan Peng pengxu...@gmail.com wrote: I am reading through the blueprint created by Randy to bind dnsmasq into qrouter- namespace: https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace I don't think I can follow the reason that we need to change the namespace which contains dnsmasq process and the device it listens to from qdhcp- to qrouter-. Why the original namespace design conflicts with the Router Advertisement sending from dnsmasq for SLAAC? From the attached POC result link, the reason is stated as: Even if the dnsmasq process could send Router Advertisement, the default gateway would bind to its own link-local address in the qdhcp- namespace. As a result, traffic leaving tenant network will be drawn to DHCP interface, instead of gateway port on router. That is not desirable! Can Randy or Shixiong explain this more? Thanks! Xuhan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace
Hi, Randy: Thanks a bunch for pointing it out! Yup, you are absolutely right. What I wanted to say is why not put qg-, qr-, and ns- interfaces in the single namespace. I typed it on my small keyboard on iPhone. Sorry for the confusion. :( Shixiong On Dec 19, 2013, at 8:44 PM, Randy Tuttle randy.m.tut...@gmail.com wrote: Shixiong, I know you must have a typo in the 3rd paragraph. I think maybe you mean to include the ns- interface in that list. So why not have qg- qr- and ns- interfaces in the same namespace. Am I right? Rnady On Thu, Dec 19, 2013 at 8:31 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, Ian: The use case brought by Comcast team today during the ipv6 sub-team meeting actually proved the point I made here, instead of against it. If I didn’t explain it clearly in my previous email, here it is. I was questioning the design with two namespaces and I believe we can use a SINGLE namespace as the common container to host two services, i.e. DHCP and ROUTING. If your use case needs DHCP instance, but not ROUTING, then just launch dnsmasq in THE namespace with qr- interface; If your use case needs default GW, then add qg- interface in THE namespace. Whether it is called qdhcp or qrouter, I don’t care. It is just a label. People follow the routine to use it, simply because this is what OpenStack offers. But my question is, why? And why NOT we design the system in the way that qg- and qr- interface collocate in the same namespace? It is because we intentionally separate the service, now the system become clumsy and less efficient. As you can see in IPv6 cases, we are forced to deal with two namespaces now. It just doesn’t make any sense. Shixiong On Dec 19, 2013, at 7:27 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: Per the discussions this evening, we did identify a reason why you might need a dhcp namespace for v6 - because networks don't actually have to have routers. It's clear you need an agent in the router namespace for RAs and another one in the DHCP namespace for when the network's not connected to a router, though. We've not pinned down all the API details yet, but the plan is to implement an RA agent first, responding to subnets that router is attached to (which is very close to what Randy and Shixiong have already done). -- Ian. On 19 December 2013 14:01, Randy Tuttle randy.m.tut...@gmail.com wrote: First, dnsmasq is not being moved. Instead, it's a different instance for the attached subnet in the qrouter namespace. If it's not in the qrouter namespace, the default gateway (the local router interface) will be the interface of qdhcp namespace interface. That will cause blackhole for traffic from VM. As you know, routing tables and NAT all occur in qrouter namespace. So we want the RA to contain the local interface as default gateway in qrouter namespace Randy Sent from my iPhone On Dec 19, 2013, at 4:05 AM, Xuhan Peng pengxu...@gmail.com wrote: I am reading through the blueprint created by Randy to bind dnsmasq into qrouter- namespace: https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace I don't think I can follow the reason that we need to change the namespace which contains dnsmasq process and the device it listens to from qdhcp- to qrouter-. Why the original namespace design conflicts with the Router Advertisement sending from dnsmasq for SLAAC? From the attached POC result link, the reason is stated as: Even if the dnsmasq process could send Router Advertisement, the default gateway would bind to its own link-local address in the qdhcp- namespace. As a result, traffic leaving tenant network will be drawn to DHCP interface, instead of gateway port on router. That is not desirable! Can Randy or Shixiong explain this more? Thanks! Xuhan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman
Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
Hi, Ian: I won’t say the intent here is to replace dnsmasq-mode-keyword BP. Instead, I was trying to leverage and enhance those definitions so when dnsmasq is launched, it knows which mode it should run in. That being said, I see the value of your points and I also had lengthy discussion with Randy regarding this. We did realize that the keyword itself may not be sufficient to properly configure dnsmasq. Let us discuss that on Thursday’s IRC meeting. Randy and I had a quick glance over your document. Much of it parallels the work we did on our POC last summer, and is now being addressed across multiple BP being implemented by ourselves or with Sean Collins and IBM team's work. I will take a closer look and provide my comments. Thank you for sharing! Shixiong On Dec 18, 2013, at 6:30 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: Hey Shixiong, This is intended as a replacement for [1], correct? Do you have code for this already, or should we work with Sean's patch? There's a discussion document at [2], which is intended to be more specific behind the reasoning for the choices we make, and the interface offered to the user for these features. I'd be grateful if you could read and comment on it. -- Ian. [1] https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword [2] https://docs.google.com/document/d/1rOBOOu_OwixMStm6XJOb5PKkJA6eFbL_XCE7wlTfaPY On 18 December 2013 04:19, Randy Tuttle randy.m.tut...@gmail.com wrote: Great Shixiong. I can see that we have BPs from Sean / Da Zhao for providing the modes via the neutron client cli, but have we seen how those modes are provided through the dashboard? Randy Sent from my iPhone On Dec 17, 2013, at 9:07 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, team: I created a new blueprint to reflect the work we accomplished in the previous POC to enable dnsmasq in SLAAC mode. In addition, I took the action item two weeks ago from weekly sub-team meeting to explore DHCPv6 options. The goal was to run dnsmasq as DHCPv6 server and provide both optional information and/or IPv6 address to VM in the tenant network. Below you can find the link to the new blueprints, which are all related to the mid-term goal in Sean’s original proposal. https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless Please let me know if you have any questions. Thanks! Shixiong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
It is up to Sean to make the call, but I would love to see IBM team in the meeting. On Dec 18, 2013, at 7:09 PM, Xuhan Peng pengxu...@gmail.com wrote: Shixiong and guys, The sub team meeting is too early for china IBM folks to join although we would like to participate the discussion very much. Any chance to rotate the time so we can comment? Thanks, Xuhan On Thursday, December 19, 2013, Shixiong Shang wrote: Hi, Ian: I agree with you on the point that the way we implement it should be app agnostic. In addition, it should cover both CLI and Dashboard, so the system behavior should be consistent to end users. The keywords is just one of the many ways to implement the concept. It is based on the reality that dnsmasq is the only driver available today to the community. By the end of the day, the input from customer should be translated to one of those mode keywords. It doesn't imply the same constants have to be used as part of the CLI or Dashboard. Randy and I had lengthy discussion/debating about this topic today. We have straw-man proposal and will share with the team tomorrow. That being said, what concerned me the most at this moment is, we are not on the same page. I hope tomorrow during sub-team meeting, we can reach consensus. If you can not make it, then please set up a separate meeting to invite key placeholders so we have a chance to sort it out. Shixiong On Dec 18, 2013, at 8:25 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 18 December 2013 14:10, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, Ian: I won’t say the intent here is to replace dnsmasq-mode-keyword BP. Instead, I was trying to leverage and enhance those definitions so when dnsmasq is launched, it knows which mode it should run in. That being said, I see the value of your points and I also had lengthy discussion with Randy regarding this. We did realize that the keyword itself may not be sufficient to properly configure dnsmasq. I think the point is that the attribute on whatever object (subnet or router) that defines the behaviour should define the behaviour, in precisely the terms you're talking about, and then we should find the dnsmasq options to suit. Talking to Sean, he's good with this too, so we're all working to the same ends and it's just a matter of getting code in. Let us discuss that on Thursday’s IRC meeting. Not sure if I'll be available or not this Thursday, unfortunately. I'll try to attend but I can't make promises. Randy and I had a quick glance over your document. Much of it parallels the work we did on our POC last summer, and is now being addressed across multiple BP being implemented by ourselves or with Sean Collins and IBM team's work. I will take a closer look and provide my comments. That's great. I'm not wedded to the details in there, I'm actually more interested that we've covered everything. If you have blueprint references, add them as comments - the ipv6-feature-parity BP could do with work and if we get the links together in one place we can update it. -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options
Hi, guys: I am reading the code in “constants.py” file as part of Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options”. One thing captured my eyes is the definition of “RA_MODES”, which excluded “slaac” mode. If my understanding of “RA_MODES” is correct, i.e. the modes leverage RA, then “slaac” mode should be included. Am I correct? Thanks! Shixiong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options
Yes, the man page is a little bit confusing. The “slaac” mode requires “—enable-ra” since it needs to manipulate MOAL bits in the RA. As matter of fact, all of the modes available for IPv6 rely on “—enable-ra”. My understanding is, the ra-names option has nothing to do with RA. It resolves the problem of where to find DNS server. It should work with slaac mode or ra-stateless mode. Shixiong On Dec 17, 2013, at 10:52 AM, Xuhan Peng pengxu...@gmail.com wrote: I think slaac was original excluded to make --enable-ra not specified when only slaac is given to an subnet's dhcp mode. However, when I checked the example conf file of dnsmasq: http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example enable-ra is explained as: # Do router advertisements for all subnets where we're doing DHCPv6 # Unless overriden by ra-stateless, ra-names, et al, the router # advertisements will have the M and O bits set, so that the clients # get addresses and configuration from DHCPv6, and the A bit reset, so the # clients don't use SLAAC addresses. #enable-ra are we using --enable-ra and ra-stateless, ra-names at the same time correctly? On Tue, Dec 17, 2013 at 8:27 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, guys: I am reading the code in “constants.py” file as part of Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options”. One thing captured my eyes is the definition of “RA_MODES”, which excluded “slaac” mode. If my understanding of “RA_MODES” is correct, i.e. the modes leverage RA, then “slaac” mode should be included. Am I correct? Thanks! Shixiong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
Hi, team: I created a new blueprint to reflect the work we accomplished in the previous POC to enable dnsmasq in SLAAC mode. In addition, I took the action item two weeks ago from weekly sub-team meeting to explore DHCPv6 options. The goal was to run dnsmasq as DHCPv6 server and provide both optional information and/or IPv6 address to VM in the tenant network. Below you can find the link to the new blueprints, which are all related to the mid-term goal in Sean’s original proposal. https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless Please let me know if you have any questions. Thanks! Shixiong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Two new blueprints
Hi, stackers: Randy Tuttle created two blueprints as an augment to Sean’s proposal to improve IPv6 readiness. You can find the details here: https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port Please let us know whether you have any questions. Thanks! Shixiong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Webex Recording of IPv6 / Neutron Sync-up
Hi, Jeremy: Thank you very much for your kind words! I saw you many times before in the meetup, but didn’t get a chance to talk to you. Will grab your brain next time. :) For other stackers who also feel interested in last night presentation, here is the link to the Webex recording: https://cisco.webex.com/ciscosales/lsr.php?AT=pbSP=ECrID=73557207rKey=73240b2ec6577fc4 Shixiong On Dec 4, 2013, at 9:54 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2013-12-04 21:44:53 -0500 (-0500), Shixiong Shang wrote: [...] I was swamped today to prepare for the presentation that Randy and I jointly delivered tonight to local OpenStack community in the meet-up sponsored by Cisco. [...] Also, just wanted to congratulate you--the presentation was excellent, and I'm quite impressed to see the awesome things you're doing with IPv6 and OpenStack (locally, no less!). -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Webex Recording of IPv6 / Neutron Sync-up
Hi, Richard: Sorry it took me a while to reply your email. I was swamped today to prepare for the presentation that Randy and I jointly delivered tonight to local OpenStack community in the meet-up sponsored by Cisco. As matter of fact, we used the same slide and you can find a copy at: http://www.slideshare.net/shixiongshang1/openstack-havana-over-ipv6 Please don’t feel hesitate to let us know if you have any questions. We will be more than happy to help. Thanks for showing the interests in our work! Shixiong On Dec 4, 2013, at 10:27 AM, Richard Woo richardwoo2...@gmail.com wrote: Shixiong, Thank you for the updates, do you mind to share the slide to the openstack mailing list? Richard On Tue, Dec 3, 2013 at 11:30 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, guys: We had a great discussion tonight with stackers from Comcast, IBM, HP, Cisco and Nephos6! Here is the debrief of what we discussed during this 1-hr session: 1) Sean from Comcast provided clarification of his short-term and mid-term goals in the proposed blueprint. 2) Da Zhao, Yu Yang, and Xu Han from IBM went throughout the patches and bug fixes they submitted. 3) Brian from HP shared his view to support IPv6 and HA in the near future. 4) Shixiong from Nephos6 and Randy from Cisco presented a slide to summarize the issues they encountered during POC together with the solutions. 5) We reached consensus to leverage the work Sean, Da Zhao have done previously and integrate it with the L3 agent efforts brought by Shixiong and Randy. Please see below for Webex recording. https://cisco.webex.com/ciscosales/lsr.php?AT=pbSP=MCrID=73520027rKey=8e508b63604bb9d0 IPv6 / Neutron synch-up-20131204 0204-1 Tuesday, December 3, 2013 9:04 pm New York Time 1 Hour 4 Minutes Thanks! Shixiong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Webex Recording of IPv6 / Neutron Sync-up
Hi, Ian: For this brainstorming session, we had IBM team in Beijing and other guys on east coast of US. In order to cover two time zones 13-hr apart, we chose 9pm EST time for the convenience of us. Didn’t realize you are in Europe and next time if we have this kind of casual discussion, we will definitely send invite to the broader team on the mailer earlier and try to find a time suitable for everybody. Thanks! Shixiong On Dec 4, 2013, at 10:47 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: Next time, could you perhaps do it (a) with a bit more notice and (b) at a slightly more amenable time for us Europeans? On Tue, Dec 3, 2013 at 11:30 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, guys: We had a great discussion tonight with stackers from Comcast, IBM, HP, Cisco and Nephos6! Here is the debrief of what we discussed during this 1-hr session: 1) Sean from Comcast provided clarification of his short-term and mid-term goals in the proposed blueprint. 2) Da Zhao, Yu Yang, and Xu Han from IBM went throughout the patches and bug fixes they submitted. 3) Brian from HP shared his view to support IPv6 and HA in the near future. 4) Shixiong from Nephos6 and Randy from Cisco presented a slide to summarize the issues they encountered during POC together with the solutions. 5) We reached consensus to leverage the work Sean, Da Zhao have done previously and integrate it with the L3 agent efforts brought by Shixiong and Randy. Please see below for Webex recording. https://cisco.webex.com/ciscosales/lsr.php?AT=pbSP=MCrID=73520027rKey=8e508b63604bb9d0 IPv6 / Neutron synch-up-20131204 0204-1 Tuesday, December 3, 2013 9:04 pm New York Time 1 Hour 4 Minutes Thanks! Shixiong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Stackers Brainstorming session on Neutron IPv6
Hi, folks: We plan to host a webex meeting tonight at 9pm EST (UTC-5) to have a brainstorming session on Neutron IPv6 readiness. As suggested by Sean Collins, the chair of Neutron IPv6 sub-team, I expand the invitation to this mailer. If you are interested in this topic, please feel free to join us. Webex session info is shown below. Thanks! Shixiong Date: Tuesday, December 3, 2013 Time: 9:00 pm, Eastern Standard Time (New York, GMT-05:00) Meeting Number: 204 979 054 Meeting Password: 123456 --- To join the online meeting (Now from mobile devices!) --- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=246670217UID=2194118227PW=NM2M2ZmEzYzU2RT=MiMxMQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: 123456 4. Click Join Now. 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=246670217UID=2194118227PW=NM2M2ZmEzYzU2ORT=MiMxMQ%3D%3D ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones). “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only. The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. --- To join the teleconference only --- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350. Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 --- For assistance --- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click Support. You can contact me at: rantu...@cisco.com 1-919-392 3470 To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://cisco.webex.com/ciscosales/j.php?ED=246670217UID=2194118227ICS=UMILD=1RD=2ST=1SHA2=AhwQBsliHog-BrmhdgdkJtezFa9m02-EpIAkXSnVQOZART=MiMxMQ%3D%3D WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://cisco.webex.com/ciscosales/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going tohttps://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Webex Recording of IPv6 / Neutron Sync-up
Hi, guys: We had a great discussion tonight with stackers from Comcast, IBM, HP, Cisco and Nephos6! Here is the debrief of what we discussed during this 1-hr session: 1) Sean from Comcast provided clarification of his short-term and mid-term goals in the proposed blueprint. 2) Da Zhao, Yu Yang, and Xu Han from IBM went throughout the patches and bug fixes they submitted. 3) Brian from HP shared his view to support IPv6 and HA in the near future. 4) Shixiong from Nephos6 and Randy from Cisco presented a slide to summarize the issues they encountered during POC together with the solutions. 5) We reached consensus to leverage the work Sean, Da Zhao have done previously and integrate it with the L3 agent efforts brought by Shixiong and Randy. Please see below for Webex recording. https://cisco.webex.com/ciscosales/lsr.php?AT=pbSP=MCrID=73520027rKey=8e508b63604bb9d0 IPv6 / Neutron synch-up-20131204 0204-1 Tuesday, December 3, 2013 9:04 pm New York Time 1 Hour 4 Minutes Thanks! Shixiong___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Meeting logs from the first IRC meeting
Hi, guys: I took the action item to submit the code for review based on our discussion during the first IRC meeting. Here is the link: https://review.openstack.org/#/c/58186/ The changes we proposed are based on the POC work my friend (Randy Tuttle) and I did back in June on Grizzly and most recent update on Havana in Oct. If you are interested in the whitepaper, please unicast us. Thanks! Shixiong On Nov 21, 2013, at 5:34 PM, Collins, Sean (Contractor) sean_colli...@cable.comcast.com wrote: Meeting minutes and the logs for the Neutron IPv6 meeting has been posted. We will not meet next week, due to the Thanksgiving holiday in the US. Our next meeting will be Thursday Dec 5th - 2100 UTC, where we will review the goals from this week's meeting and look to create actionable items for I-2. [1] https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam [2] http://eavesdrop.openstack.org/meetings/neutron_ipv6/2013/ -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] compute agent cannot start
Hi, Guys: I am trying to run ceilometer agent on compute node, and it gave me the following traceback. I believe I hit this bug (https://bugs.launchpad.net/nova/+bug/1244055”). However, I would like to know whether there is any workaround? sudo python /usr/local/bin/ceilometer-agent-compute Traceback (most recent call last): File /usr/local/bin/ceilometer-agent-compute, line 6, in module from ceilometer.compute.manager import agent_compute File /usr/local/lib/python2.7/dist-packages/ceilometer/compute/manager.py, line 22, in module from ceilometer import agent File /usr/local/lib/python2.7/dist-packages/ceilometer/agent.py, line 24, in module from ceilometer import pipeline File /usr/local/lib/python2.7/dist-packages/ceilometer/pipeline.py, line 28, in module from ceilometer import publisher File /usr/local/lib/python2.7/dist-packages/ceilometer/publisher/__init__.py, line 40, in module @six.add_metaclass(abc.ABCMeta) AttributeError: 'module' object has no attribute ‘add_metaclass' Thanks! Shixiong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] compute agent cannot start
I see, that resolved the issue. No complain of VersionConflict any more.
However, now, it is back to square one. :( The odd thing is, I do see
add_metaclass in the six.py. I am confused. What's going on?
ceilometer-agent-compute
Traceback (most recent call last):
File /usr/local/bin/ceilometer-agent-compute, line 6, in module
from ceilometer.compute.manager import agent_compute
File
/usr/local/lib/python2.7/dist-packages/ceilometer/compute/manager.py,
line 22, in module
from ceilometer import agent
File /usr/local/lib/python2.7/dist-packages/ceilometer/agent.py, line
24, in module
from ceilometer import pipeline
File /usr/local/lib/python2.7/dist-packages/ceilometer/pipeline.py,
line 28, in module
from ceilometer import publisher
File
/usr/local/lib/python2.7/dist-packages/ceilometer/publisher/__init__.py,
line 40, in module
@six.add_metaclass(abc.ABCMeta)
AttributeError: 'module' object has no attribute 'add_metaclass'
Shixiong
On Thu, Nov 14, 2013 at 9:43 PM, Lu, Lianhao lianhao...@intel.com wrote:
How do you replace, just manual copying? I think you should pip install -U
six.
Best Regards,
Lianhao
-Original Message-
From: Shixiong Shang [mailto:sparkofwisdom.cl...@gmail.com]
Sent: Friday, November 15, 2013 10:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ceilometer] compute agent cannot start
Hi, Lianhao:
I downloaded six package, 1.4.1 from pypi.python.org and replaced all
six.py files with the latest version, including the one under
/usr/lib/python2.7/dist-packages directory.
more /usr/lib/python2.7/dist-packages/six.py
import operator
import sys
import types
__author__ = Benjamin Peterson benja...@python.org
__version__ = 1.4.1
However, ceilometer-agent-compute still complained of VersionConflict.
18:30:04.376 11553 ERROR stevedore.extension [-] Could not load
'libvirt': (six 1.3.0 (/usr/lib/python2.7/dist-packages),
Requirement.parse('six=1.4.1'))
2013-11-14 18:30:04.376 11553 ERROR stevedore.extension [-] (six 1.3.0
(/usr/lib/python2.7/dist-packages),
Requirement.parse('six=1.4.1'))
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension Traceback (most
recent call last):
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension File
/usr/lib/python2.7/dist-packages/stevedore/extension.py, line 89, in
_load_plugins
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension invoke_kwds,
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension File
/usr/lib/python2.7/dist-packages/stevedore/named.py, line 57, in
_load_one_plugin
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension ep,
invoke_on_load, invoke_args, invoke_kwds,
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension File
/usr/lib/python2.7/dist-packages/stevedore/extension.py, line 101, in
_load_one_plugin
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension plugin =
ep.load()
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension File
build/bdist.linux-x86_64/egg/pkg_resources.py, line 2107, in load
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension if require:
self.require(env, installer)
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension File
build/bdist.linux-x86_64/egg/pkg_resources.py, line 2120, in require
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension
working_set.resolve(self.dist.requires(self.extras),env,installer)))
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension File
build/bdist.linux-x86_64/egg/pkg_resources.py, line 580, in resolve
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension raise
VersionConflict(dist,req) # XXX put more info here
2013-11-14 18:30:04.376 11553 TRACE stevedore.extension VersionConflict:
(six 1.3.0 (/usr/lib/python2.7/dist-packages),
Requirement.parse('six=1.4.1'))
Thanks!
Shixiong
On Thu, Nov 14, 2013 at 9:02 PM, Lu, Lianhao lianhao...@intel.com
wrote:
Which version of six do you have? I think you at least need six
1.4.0
-Lianhao
-Original Message-
From: Shixiong Shang [mailto:sparkofwisdom.cl...@gmail.com]
Sent: Friday, November 15, 2013 4:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Ceilometer] compute agent cannot start
Hi, Guys:
I am trying to run ceilometer agent on compute node, and it gave
me the following traceback. I believe I hit this bug
(https://bugs.launchpad.net/nova/+bug/1244055;). However, I
would like to know whether there is any workaround?
sudo python /usr/local/bin/ceilometer-agent-compute
Traceback (most recent call last):
File /usr/local/bin/ceilometer-agent-compute, line 6, in
module
from ceilometer.compute.manager import
Re: [openstack-dev] [neutron] [ipv6] IPv6 meeting - Thursdays 21:00UTC - #openstack-meeting-alt
Hi, Sean: Thanks a bunch for finalizing the time! Sorry for my ignorance….how do we usually run the meeting? On Webex or IRC channel? Look forward to it! Shixiong On Nov 13, 2013, at 9:32 AM, Collins, Sean (Contractor) sean_colli...@cable.comcast.com wrote: I haven't heard any negative response to the proposed time, so I'd like to put a stake in the ground and utilize that time slot. We will have our first meeting on Nov 21st. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Ceilometer installation problem
Hi, guys:
I am trying to install Ceilometer on Ubuntu 13.10 Cloud version (64-bit) and
encounter the following error. Would you please help?
Thanks!
Shixiong
root@net-meter2:/opt/stack/ceilometer# sudo python setup.py install
snipped
creating build/temp.linux-x86_64-2.7/src
creating build/temp.linux-x86_64-2.7/src/lxml
x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2
-Wall -Wstrict-prototypes -fPIC -I/tmp/pip_build_root/lxml/src/lxml/includes
-I/usr/include/python2.7 -c src/lxml/lxml.etree.c -o
build/temp.linux-x86_64-2.7/src/lxml/lxml.etree.o
src/lxml/lxml.etree.c:8:22: fatal error: pyconfig.h: No such file or directory
#include pyconfig.h
^
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
Cleaning up...
Command /usr/bin/python -c import
setuptools;__file__='/tmp/pip_build_root/lxml/setup.py';exec(compile(open(__file__).read().replace('\r\n',
'\n'), __file__, 'exec')) install --record
/tmp/pip-AaopVj-record/install-record.txt --single-version-externally-managed
failed with error code 1 in /tmp/pip_build_root/lxml
Traceback (most recent call last):
File /usr/lib/python2.7/runpy.py, line 162, in _run_module_as_main
__main__, fname, loader, pkg_name)
File /usr/lib/python2.7/runpy.py, line 72, in _run_code
exec code in run_globals
File /usr/lib/python2.7/dist-packages/pip/__init__.py, line 233, in module
exit = main()
File /usr/lib/python2.7/dist-packages/pip/__init__.py, line 148, in main
return command.main(args[1:], options)
File /usr/lib/python2.7/dist-packages/pip/basecommand.py, line 169, in main
text = '\n'.join(complete_log)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 42:
ordinal not in range(128)
error: ['/usr/bin/python', '-m', 'pip.__init__', 'install', 'pbr=0.5.21,1.0',
'WebOb=1.2.3,1.3', 'kombu=2.4.8', 'iso8601=0.1.8',
'SQLAlchemy=0.7.8,=0.7.99', 'sqlalchemy-migrate=0.7.2', 'alembic=0.4.1',
'netaddr=0.7.6', 'pymongo=2.4', 'eventlet=0.13.0', 'anyjson=0.3.3',
'Flask=0.10,1.0', 'pecan=0.2.0', 'stevedore=0.10', 'msgpack-python',
'python-glanceclient=0.9.0', 'python-novaclient=2.15.0',
'python-keystoneclient=0.4.1', 'python-ceilometerclient=1.0.6',
'python-swiftclient=1.5', 'lxml=2.3', 'requests=1.1', 'six=1.4.1',
'WSME=0.5b6', 'PyYAML=3.1.0', 'oslo.config=1.2.0', 'happybase=0.4']
returned 1
root@net-meter2:/opt/stack/ceilometer#
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 sub-team?
Thanks, Sean! I am on east coast, so Monday 20:00 UTC time and Thursday 21:00 UTC time work great for me. Hopefully we can find a timeslot working for everybody! Shixiong On Nov 11, 2013, at 1:23 PM, Collins, Sean (Contractor) sean_colli...@cable.comcast.com wrote: On Mon, Nov 11, 2013 at 01:16:43PM -0500, Shixiong Shang wrote: +1. We have great interest to run OpenStack over IPv6 and would love to be a part of the discussion. Excellent - please see the thread I've made in OpenStack-Dev - we're tossing out times for the IRC meeting, that works for everyone interested. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
