[openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron
My team just ran into an issue where neutron was not passing unit tests when run under Python 2.6. We tracked this down to a test support function using collections.OrderedDict. This was in locally forked code, but when I compared it to upstream code, I found that the code in upstream neutron is identical…meaning that upstream neutron cannot possibly be passing unit tests under Python 2.6. Yet, somehow, the neutron reviews I've looked at are passing the Python 2.6 gate! Any ideas as to how this could be happening? For the record, the problem is in neutron/tests/unit/test_api_v2.py:148, in the function _get_collection_kwargs(), which uses collections.OrderedDict. As there's no reason to use OrderedDict here that I can see—there's no definite order on the initialization, and all consumers pass it to an assert_called_once_with() method with the '**' operator—I have proposed a review[1] to replace it with a simple dict. [1] https://review.openstack.org/#/c/123189/ -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron
What about: https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12 On 22 September 2014 10:23, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: My team just ran into an issue where neutron was not passing unit tests when run under Python 2.6. We tracked this down to a test support function using collections.OrderedDict. This was in locally forked code, but when I compared it to upstream code, I found that the code in upstream neutron is identical…meaning that upstream neutron cannot possibly be passing unit tests under Python 2.6. Yet, somehow, the neutron reviews I've looked at are passing the Python 2.6 gate! Any ideas as to how this could be happening? For the record, the problem is in neutron/tests/unit/test_api_v2.py:148, in the function _get_collection_kwargs(), which uses collections.OrderedDict. As there's no reason to use OrderedDict here that I can see—there's no definite order on the initialization, and all consumers pass it to an assert_called_once_with() method with the '**' operator—I have proposed a review[1] to replace it with a simple dict. [1] https://review.openstack.org/#/c/123189/ -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ 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] [infra] Python 2.6 tests can't possibly be passing in neutron
On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote: What about: https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12 Pulling in ordereddict doesn't do anything if your code doesn't use it when OrderedDict isn't in collections, which is the case here. Further, there's no reason that _get_collection_kwargs() needs to use an OrderedDict: it's initialized in an arbitrary order (generator comprehension over a set), then later passed to functions with **, which converts it to a plain old dict. -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron
On 09/22/2014 10:58 AM, Kevin L. Mitchell wrote: On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote: What about: https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12 Pulling in ordereddict doesn't do anything if your code doesn't use it when OrderedDict isn't in collections, which is the case here. Further, there's no reason that _get_collection_kwargs() needs to use an OrderedDict: it's initialized in an arbitrary order (generator comprehension over a set), then later passed to functions with **, which converts it to a plain old dict. So - as an update to this, this is due to RedHat once again choosing to backport features from 2.7 into a thing they have labeled 2.6. We test 2.6 on Centos6 - which means we get RedHat's patched version of Python2.6 - which, it turns out, isn't really 2.6 - so while you might want to assume that we're testing 2.6 - we're not - we're testing 2.6-as-it-appears-in-RHEL. This brings up a question - in what direction do we care/what's the point in the first place? Some points to ponder: - 2.6 is end of life - so the fact that this is coming up is silly, we should have stopped caring about it in OpenStack 2 years ago at least - Maybe we ACTUALLY only care about 2.6-on-RHEL - since that was the point of supporting it at all - Maybe we ACTUALLY care about 2.6 support across the board, in which case we should STOP testing using Centos6 which is not actually 2.6 I vote for just amending our policy right now and killing 2.6 with prejudice. (also, I have heard a rumor that there are people running in to problems due to the fact that they are deploying onto a two-release-old version of Debian. No offense - but there is no way we're supporting that) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron
Just as an update to what exactly is RHEL python 2.6... This is the expanded source rpm: http://paste.ubuntu.com/8405074/ The main one here appears to be: - python-2.6.6-ordereddict-backport.patch Full changelog @ http://paste.ubuntu.com/8405082/ Overall I'd personally like to get rid of python 2.6, and move on, but then I'd also like to get rid of 2.7 and move on also ;) - Josh On Sep 22, 2014, at 11:17 AM, Monty Taylor mord...@inaugust.com wrote: On 09/22/2014 10:58 AM, Kevin L. Mitchell wrote: On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote: What about: https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12 Pulling in ordereddict doesn't do anything if your code doesn't use it when OrderedDict isn't in collections, which is the case here. Further, there's no reason that _get_collection_kwargs() needs to use an OrderedDict: it's initialized in an arbitrary order (generator comprehension over a set), then later passed to functions with **, which converts it to a plain old dict. So - as an update to this, this is due to RedHat once again choosing to backport features from 2.7 into a thing they have labeled 2.6. We test 2.6 on Centos6 - which means we get RedHat's patched version of Python2.6 - which, it turns out, isn't really 2.6 - so while you might want to assume that we're testing 2.6 - we're not - we're testing 2.6-as-it-appears-in-RHEL. This brings up a question - in what direction do we care/what's the point in the first place? Some points to ponder: - 2.6 is end of life - so the fact that this is coming up is silly, we should have stopped caring about it in OpenStack 2 years ago at least - Maybe we ACTUALLY only care about 2.6-on-RHEL - since that was the point of supporting it at all - Maybe we ACTUALLY care about 2.6 support across the board, in which case we should STOP testing using Centos6 which is not actually 2.6 I vote for just amending our policy right now and killing 2.6 with prejudice. (also, I have heard a rumor that there are people running in to problems due to the fact that they are deploying onto a two-release-old version of Debian. No offense - but there is no way we're supporting that) ___ 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] [infra] Python 2.6 tests can't possibly be passing in neutron
I'm in favor of killing Python 2.6 with fire. Honestly, I think it's hurting code readability and productivity -- You have to constantly think about whether or not some feature that the rest of the universe is already using is supported in Python 2.6 whenever you write code. As for readability, things like 'contextlib.nested' can go away if we can kill Python 2.6 (Python 2.7 supports nested context managers OOTB, in a much more readable way). Best Regards, Solly - Original Message - From: Joshua Harlow harlo...@outlook.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, September 22, 2014 2:33:16 PM Subject: Re: [openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron Just as an update to what exactly is RHEL python 2.6... This is the expanded source rpm: http://paste.ubuntu.com/8405074/ The main one here appears to be: - python-2.6.6-ordereddict-backport.patch Full changelog @ http://paste.ubuntu.com/8405082/ Overall I'd personally like to get rid of python 2.6, and move on, but then I'd also like to get rid of 2.7 and move on also ;) - Josh On Sep 22, 2014, at 11:17 AM, Monty Taylor mord...@inaugust.com wrote: On 09/22/2014 10:58 AM, Kevin L. Mitchell wrote: On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote: What about: https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12 Pulling in ordereddict doesn't do anything if your code doesn't use it when OrderedDict isn't in collections, which is the case here. Further, there's no reason that _get_collection_kwargs() needs to use an OrderedDict: it's initialized in an arbitrary order (generator comprehension over a set), then later passed to functions with **, which converts it to a plain old dict. So - as an update to this, this is due to RedHat once again choosing to backport features from 2.7 into a thing they have labeled 2.6. We test 2.6 on Centos6 - which means we get RedHat's patched version of Python2.6 - which, it turns out, isn't really 2.6 - so while you might want to assume that we're testing 2.6 - we're not - we're testing 2.6-as-it-appears-in-RHEL. This brings up a question - in what direction do we care/what's the point in the first place? Some points to ponder: - 2.6 is end of life - so the fact that this is coming up is silly, we should have stopped caring about it in OpenStack 2 years ago at least - Maybe we ACTUALLY only care about 2.6-on-RHEL - since that was the point of supporting it at all - Maybe we ACTUALLY care about 2.6 support across the board, in which case we should STOP testing using Centos6 which is not actually 2.6 I vote for just amending our policy right now and killing 2.6 with prejudice. (also, I have heard a rumor that there are people running in to problems due to the fact that they are deploying onto a two-release-old version of Debian. No offense - but there is no way we're supporting that) ___ 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] [infra] Python 2.6 tests can't possibly be passing in neutron
I suspect that the very reason underlying the existence of this thread is that some users out there are not quite ready to pull the plug on Python 2.6. Any decision about stopping the support of Python 2.6 should not be taken solely on making the developer's life easier, but maybe I am stating the obvious. Thanks, Armando On 22 September 2014 11:39, Solly Ross sr...@redhat.com wrote: I'm in favor of killing Python 2.6 with fire. Honestly, I think it's hurting code readability and productivity -- You have to constantly think about whether or not some feature that the rest of the universe is already using is supported in Python 2.6 whenever you write code. As for readability, things like 'contextlib.nested' can go away if we can kill Python 2.6 (Python 2.7 supports nested context managers OOTB, in a much more readable way). Best Regards, Solly - Original Message - From: Joshua Harlow harlo...@outlook.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, September 22, 2014 2:33:16 PM Subject: Re: [openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron Just as an update to what exactly is RHEL python 2.6... This is the expanded source rpm: http://paste.ubuntu.com/8405074/ The main one here appears to be: - python-2.6.6-ordereddict-backport.patch Full changelog @ http://paste.ubuntu.com/8405082/ Overall I'd personally like to get rid of python 2.6, and move on, but then I'd also like to get rid of 2.7 and move on also ;) - Josh On Sep 22, 2014, at 11:17 AM, Monty Taylor mord...@inaugust.com wrote: On 09/22/2014 10:58 AM, Kevin L. Mitchell wrote: On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote: What about: https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12 Pulling in ordereddict doesn't do anything if your code doesn't use it when OrderedDict isn't in collections, which is the case here. Further, there's no reason that _get_collection_kwargs() needs to use an OrderedDict: it's initialized in an arbitrary order (generator comprehension over a set), then later passed to functions with **, which converts it to a plain old dict. So - as an update to this, this is due to RedHat once again choosing to backport features from 2.7 into a thing they have labeled 2.6. We test 2.6 on Centos6 - which means we get RedHat's patched version of Python2.6 - which, it turns out, isn't really 2.6 - so while you might want to assume that we're testing 2.6 - we're not - we're testing 2.6-as-it-appears-in-RHEL. This brings up a question - in what direction do we care/what's the point in the first place? Some points to ponder: - 2.6 is end of life - so the fact that this is coming up is silly, we should have stopped caring about it in OpenStack 2 years ago at least - Maybe we ACTUALLY only care about 2.6-on-RHEL - since that was the point of supporting it at all - Maybe we ACTUALLY care about 2.6 support across the board, in which case we should STOP testing using Centos6 which is not actually 2.6 I vote for just amending our policy right now and killing 2.6 with prejudice. (also, I have heard a rumor that there are people running in to problems due to the fact that they are deploying onto a two-release-old version of Debian. No offense - but there is no way we're supporting that) ___ 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] [infra] Python 2.6 tests can't possibly be passing in neutron
My general understanding is 2.6 support is deprecated for Juno, and fair to be removed in Kilo. So the killing it with fire should be able to happen soon. -Sean On 09/22/2014 02:52 PM, Armando M. wrote: I suspect that the very reason underlying the existence of this thread is that some users out there are not quite ready to pull the plug on Python 2.6. Any decision about stopping the support of Python 2.6 should not be taken solely on making the developer's life easier, but maybe I am stating the obvious. Thanks, Armando On 22 September 2014 11:39, Solly Ross sr...@redhat.com wrote: I'm in favor of killing Python 2.6 with fire. Honestly, I think it's hurting code readability and productivity -- You have to constantly think about whether or not some feature that the rest of the universe is already using is supported in Python 2.6 whenever you write code. As for readability, things like 'contextlib.nested' can go away if we can kill Python 2.6 (Python 2.7 supports nested context managers OOTB, in a much more readable way). Best Regards, Solly - Original Message - From: Joshua Harlow harlo...@outlook.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Monday, September 22, 2014 2:33:16 PM Subject: Re: [openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron Just as an update to what exactly is RHEL python 2.6... This is the expanded source rpm: http://paste.ubuntu.com/8405074/ The main one here appears to be: - python-2.6.6-ordereddict-backport.patch Full changelog @ http://paste.ubuntu.com/8405082/ Overall I'd personally like to get rid of python 2.6, and move on, but then I'd also like to get rid of 2.7 and move on also ;) - Josh On Sep 22, 2014, at 11:17 AM, Monty Taylor mord...@inaugust.com wrote: On 09/22/2014 10:58 AM, Kevin L. Mitchell wrote: On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote: What about: https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12 Pulling in ordereddict doesn't do anything if your code doesn't use it when OrderedDict isn't in collections, which is the case here. Further, there's no reason that _get_collection_kwargs() needs to use an OrderedDict: it's initialized in an arbitrary order (generator comprehension over a set), then later passed to functions with **, which converts it to a plain old dict. So - as an update to this, this is due to RedHat once again choosing to backport features from 2.7 into a thing they have labeled 2.6. We test 2.6 on Centos6 - which means we get RedHat's patched version of Python2.6 - which, it turns out, isn't really 2.6 - so while you might want to assume that we're testing 2.6 - we're not - we're testing 2.6-as-it-appears-in-RHEL. This brings up a question - in what direction do we care/what's the point in the first place? Some points to ponder: - 2.6 is end of life - so the fact that this is coming up is silly, we should have stopped caring about it in OpenStack 2 years ago at least - Maybe we ACTUALLY only care about 2.6-on-RHEL - since that was the point of supporting it at all - Maybe we ACTUALLY care about 2.6 support across the board, in which case we should STOP testing using Centos6 which is not actually 2.6 I vote for just amending our policy right now and killing 2.6 with prejudice. (also, I have heard a rumor that there are people running in to problems due to the fact that they are deploying onto a two-release-old version of Debian. No offense - but there is no way we're supporting that) ___ 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 -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron
On 2014-09-22 14:56:04 -0400 (-0400), Sean Dague wrote: My general understanding is 2.6 support is deprecated for Juno, and fair to be removed in Kilo. So the killing it with fire should be able to happen soon. However, we will still need to continue testing changes to stable/icehouse and stable/juno on it (the latter perhaps something like a year from its first release, though that remains to be discussed at the upcoming summit). What's perhaps *not* immediately obvious to everyone is that means we also need to continue testing clients and libraries on it for the duration as well, since the stable server releases will continue needing to use them. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [infra] Python 2.6 tests can't possibly be passing in neutron
On Sep 22, 2014, at 2:17 PM, Monty Taylor mord...@inaugust.com wrote: On 09/22/2014 10:58 AM, Kevin L. Mitchell wrote: On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote: What about: https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12 Pulling in ordereddict doesn't do anything if your code doesn't use it when OrderedDict isn't in collections, which is the case here. Further, there's no reason that _get_collection_kwargs() needs to use an OrderedDict: it's initialized in an arbitrary order (generator comprehension over a set), then later passed to functions with **, which converts it to a plain old dict. So - as an update to this, this is due to RedHat once again choosing to backport features from 2.7 into a thing they have labeled 2.6. We test 2.6 on Centos6 - which means we get RedHat's patched version of Python2.6 - which, it turns out, isn't really 2.6 - so while you might want to assume that we're testing 2.6 - we're not - we're testing 2.6-as-it-appears-in-RHEL. This brings up a question - in what direction do we care/what's the point in the first place? Some points to ponder: - 2.6 is end of life - so the fact that this is coming up is silly, we should have stopped caring about it in OpenStack 2 years ago at least - Maybe we ACTUALLY only care about 2.6-on-RHEL - since that was the point of supporting it at all - Maybe we ACTUALLY care about 2.6 support across the board, in which case we should STOP testing using Centos6 which is not actually 2.6 I vote for just amending our policy right now and killing 2.6 with prejudice. At the summit we said we would drop 2.6 for kilo [1], so dropping support for 2.7 soon is right in line with our proposed schedule. The etherpad also mentions that we were waiting on some pronouncement from SLES about when they would be moving to 2.7. Do we have that? On line 33 of [1] we said we would continue to maintain support for 2.6 in the clients for a long as we had stable branches supporting 2.6. Do we want that to be 2.6-on-RHEL or 2.6 from upstream (i.e., we build our own 2.6 package so we can be sure we aren’t bringing in any features that have been backported)? Doug [1] https://etherpad.openstack.org/p/juno-cross-project-future-of-python (also, I have heard a rumor that there are people running in to problems due to the fact that they are deploying onto a two-release-old version of Debian. No offense - but there is no way we're supporting that) ___ 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] [infra] Python 2.6 tests can't possibly be passing in neutron
On Sep 22, 2014, at 3:43 PM, Doug Hellmann d...@doughellmann.com wrote: On Sep 22, 2014, at 2:17 PM, Monty Taylor mord...@inaugust.com wrote: On 09/22/2014 10:58 AM, Kevin L. Mitchell wrote: On Mon, 2014-09-22 at 10:32 -0700, Armando M. wrote: What about: https://github.com/openstack/neutron/blob/master/test-requirements.txt#L12 Pulling in ordereddict doesn't do anything if your code doesn't use it when OrderedDict isn't in collections, which is the case here. Further, there's no reason that _get_collection_kwargs() needs to use an OrderedDict: it's initialized in an arbitrary order (generator comprehension over a set), then later passed to functions with **, which converts it to a plain old dict. So - as an update to this, this is due to RedHat once again choosing to backport features from 2.7 into a thing they have labeled 2.6. We test 2.6 on Centos6 - which means we get RedHat's patched version of Python2.6 - which, it turns out, isn't really 2.6 - so while you might want to assume that we're testing 2.6 - we're not - we're testing 2.6-as-it-appears-in-RHEL. This brings up a question - in what direction do we care/what's the point in the first place? Some points to ponder: - 2.6 is end of life - so the fact that this is coming up is silly, we should have stopped caring about it in OpenStack 2 years ago at least - Maybe we ACTUALLY only care about 2.6-on-RHEL - since that was the point of supporting it at all - Maybe we ACTUALLY care about 2.6 support across the board, in which case we should STOP testing using Centos6 which is not actually 2.6 I vote for just amending our policy right now and killing 2.6 with prejudice. At the summit we said we would drop 2.6 for kilo [1], so dropping support for 2.7 soon is right in line with our proposed schedule. Oops, typo. Let’s keep 2.7 and drop 2.6. :-) The etherpad also mentions that we were waiting on some pronouncement from SLES about when they would be moving to 2.7. Do we have that? On line 33 of [1] we said we would continue to maintain support for 2.6 in the clients for a long as we had stable branches supporting 2.6. Do we want that to be 2.6-on-RHEL or 2.6 from upstream (i.e., we build our own 2.6 package so we can be sure we aren’t bringing in any features that have been backported)? Doug [1] https://etherpad.openstack.org/p/juno-cross-project-future-of-python (also, I have heard a rumor that there are people running in to problems due to the fact that they are deploying onto a two-release-old version of Debian. No offense - but there is no way we're supporting that) ___ 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
