Re: [openstack-dev] OK to Use Flufl.enum
from flufl.enum import IntEnum class A(IntEnum): ... a = 3 ... A.a EnumValue: A.a [value=3] Alex On Tue, Dec 10, 2013 at 8:23 AM, Jay Pipes jaypi...@gmail.com wrote: On 12/10/2013 09:55 AM, Adam Young wrote: On 12/10/2013 05:24 AM, Flavio Percoco wrote: On 09/12/13 19:45 -0800, Alex Gaynor wrote: Would it make sense to use the `enum34` package, which is a backport of teh enum package from py3k? +1 This is what we were using in Marconi. So... they seem to be doing something different from Flufl, as IntEnums are not working the same way. I wonder if it is just update lag, and Flufl is the Upstream for the changes. With only a change to the import and requirements, it builds and runs, but raises: Traceback (most recent call last): File keystone/tests/test_revoke.py, line 65, in test_list_is_sorted valid_until=valid_until)) File keystone/contrib/revoke/core.py, line 74, in __init__ setattr(self, k, v) File keystone/contrib/revoke/core.py, line 82, in scope_type self._scope_type = ScopeType[value] File /opt/stack/keystone/.venv/lib/python2.7/site-packages/enum/__init__.py, line 352, in __getitem__ return cls._member_map_[name] KeyError: 1 This seems to say that you cannot access an IntEnum as an integer, which just seems broken. What precisely is the benefit of an IntEnum? From the example in the flufl.enum docs: from flufl.enum import IntEnum class Animals(IntEnum): ... ant = 1 ... bee = 2 ... cat = 3 int(Animals.bee) 2 Wow. That is so amazing. Thank goodness there is a library for that. Oh wait... I can do exactly the same thing without flufl.enum or any other library: class Animals: ... ant = 1 ... bee = 2 ... cat = 3 ... int(Animals.bee) 2 The IntEnum is my new definition of the most worthless class ever invented in the Python ecosystem -- taking the place of zope.interface on my personal wall of worthlessness. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OK to Use Flufl.enum
Would it make sense to use the `enum34` package, which is a backport of teh enum package from py3k? Alex On Mon, Dec 9, 2013 at 7:37 PM, Adam Young ayo...@redhat.com wrote: While Python 3 has enumerated types, Python 2 does not, and the standard package to provide id, Flufl.enum, is not yet part of our code base. Is there any strong objection to including Flufl.enum? http://pythonhosted.org/flufl.enum/ It makes for some very elegant code, especially for enumerated integer types. For an example See ScopeType in https://review.openstack.org/#/c/55908/4/keystone/contrib/revoke/core.py Line 62. the getter/setter in RevokeEvent do not need to do any conditional logic if passed either an integer or a ScopeType. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Top Gate Bugs
Nope, you're totally right, corolocal.local is a class, whose instances are the actual coroutine local storage. Alex On Wed, Nov 20, 2013 at 9:11 AM, Roman Podoliaka rpodoly...@mirantis.comwrote: Hey all, I think I found a serious bug in our usage of eventlet thread local storage. Please check out this snippet [1]. This is how we use eventlet TLS in Nova and common Oslo code [2]. This could explain how [3] actually breaks TripleO devtest story and our gates. Am I right? Or I am missing something and should get some sleep? :) Thanks, Roman [1] http://paste.openstack.org/show/53686/ [2] https://github.com/openstack/nova/blob/master/nova/openstack/common/local.py#L48 [3] https://github.com/openstack/nova/commit/85332012dede96fa6729026c2a90594ea0502ac5 On Wed, Nov 20, 2013 at 5:55 PM, Derek Higgins der...@redhat.com wrote: On 20/11/13 14:21, Anita Kuno wrote: Thanks for posting this, Joe. It really helps to create focus so we can address these bugs. We are chatting in #openstack-neutron about 1251784, 1249065, and 1251448. We are looking for someone to work on 1251784 - I had mentioned it at Monday's Neutron team meeting and am trying to shop it around in -neutron now. We need someone other than Salvatore, Aaron or Maru to work on this since they each have at least one very important bug they are working on. Please join us in #openstack-neutron and lend a hand - all of OpenStack needs your help. I've been hitting this in tripleo intermittently for the last few days (or it at least looks to be the same bug), this morning while trying to debug the problem I noticed http request/responses happening out of order. I've added details to the bug. https://bugs.launchpad.net/tripleo/+bug/1251784 Bug 1249065 is assigned to Aaron Rosen, who isn't in the channel at the moment, so I don't have an update on his progress or any blockers he is facing. Hopefully (if you are reading this Aaron) he will join us in channel soon and I had hear from him about his status. Bug 1251448 is assigned to Maru Newby, who I am talking with now in -neutron. He is addressing the bug. I will share what information I have regarding this one when I have some. We are all looking forward to a more stable gate and this information really helps. Thanks again, Joe, Anita. On 11/20/2013 01:09 AM, Joe Gordon wrote: Hi All, As many of you have noticed the gate has been in very bad shape over the past few days. Here is a list of some of the top open bugs (without pending patches, and many recent hits) that we are hitting. Gate won't be stable, and it will be hard to get your code merged, until we fix these bugs. 1) https://bugs.launchpad.net/bugs/1251920 nova 468 Hits 2) https://bugs.launchpad.net/bugs/1251784 neutron, Nova 328 Hits 3) https://bugs.launchpad.net/bugs/1249065 neutron 122 hits 4) https://bugs.launchpad.net/bugs/1251448 neutron 65 Hits Raw Data: Note: If a bug has any hits for anything besides failure, it means the fingerprint isn't perfect. Elastic recheck known issues Bug: https://bugs.launchpad.net/bugs/1251920 = message:assertionerror: console output was empty AND filename:console.html Title: Tempest failures due to failure to return console logs from an instance Project: Status nova: Confirmed Hits FAILURE: 468 Bug: https://bugs.launchpad.net/bugs/1251784 = message:Connection to neutron failed: Maximum attempts reached AND filename:logs/screen-n-cpu.txt Title: nova+neutron scheduling error: Connection to neutron failed: Maximum attempts reached Project: Status neutron: New nova: New Hits FAILURE: 328 UNSTABLE: 13 SUCCESS: 275 Bug: https://bugs.launchpad.net/bugs/1240256= message: 503 AND filename:logs/syslog.txt AND syslog_program:proxy-server Title: swift proxy-server returning 503 during tempest run Project: Status openstack-ci: Incomplete swift: New tempest: New Hits FAILURE: 136 SUCCESS: 83 Pending Patch Bug: https://bugs.launchpad.net/bugs/1249065 = message:No nw_info cache associated with instance AND filename:logs/screen-n-api.txt Title: Tempest failure: tempest/scenario/test_snapshot_pattern.py Project: Status neutron: New nova: Confirmed Hits FAILURE: 122 Bug: https://bugs.launchpad.net/bugs/1252514 = message:Got error from Swift: put_object AND filename:logs/screen-g-api.txt Title: glance doesn't recover if Swift returns an error Project: Status devstack: New glance: New swift: New Hits FAILURE: 95 Pending Patch Bug: https://bugs.launchpad.net/bugs/1244255 = message:NovaException: Unexpected vif_type=binding_failed AND filename:logs/screen-n-cpu.txt Title: binding_failed because of l2 agent assumed down Project: Status neutron: Fix Committed Hits FAILURE: 92 SUCCESS: 29 Bug: https://bugs.launchpad.net/bugs/1251448 = message: possible networks found, use a Network ID to be more specific. (HTTP
Re: [openstack-dev] [Solum] SFO Design Workshop
It's worth noting that right now, just a few blocks from the office DreamForce is going on, so it's going to be crowded, I strongly recommend avoiding driving if you can. Alex On Mon, Nov 18, 2013 at 9:50 AM, Adrian Otto adrian.o...@rackspace.comwrote: No, it does not have any parking. I suggest coming in on BART and exit at the Montgomery station and coming south on 2nd to Folsom by foot. The Courtyard hotel across the street has parking but that is very expensive and may be full. Parking at the meters on the street is not a great option either. -- Adrian Original message From: Clayton Coleman Date:11/18/2013 9:43 AM (GMT-08:00) To: OpenStack Development Mailing List (not for usage questions) Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] SFO Design Workshop Is there easy parking at the rackspace office? On Nov 18, 2013, at 7:33 AM, Adrian Otto adrian.o...@rackspace.com wrote: No. Registration is for in person attendance only. -- Adrian Original message From: Rajdeep Dua Date:11/18/2013 5:39 AM (GMT-08:00) To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] SFO Design Workshop Do we need to register on event brite if joining over IRC / Google Hangout? On Saturday, November 16, 2013 3:43 AM, Roshan Agrawal roshan.agra...@rackspace.com wrote: We are all set for the Solum design workshops at SFO on Nov 19,20. The etherpad page below has schedule and agenda details https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop Please sign up as topic leads/scribe for the sessions listed in the agenda. We also have etherpad pages setup for each track of discussion, and we can fill in content right away to prep for the lively discussions next week. We also have a happy hour planned on the evening of Tuesday, and have lunch arrangements on the house. Looking forward to a fun and productive two days at SFO! Thanks Regards, Roshan Agrawal Direct:512.874.1278 Mobile: 512.354.5253 roshan.agra...@rackspace.com ___ 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 -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Announce of Rally - benchmarking system for OpenStack
There's several issues involved in doing automated regression checking for benchmarks: - You need a platform which is stable. Right now all our CI runs on virtualized instances, and I don't think there's any particular guarantee it'll be the same underlying hardware, further virtualized systems tend to be very noisy and not give you the stability you need. - You need your benchmarks to be very high precision, if you really want to rule out regressions of more than N% without a lot of false positives. - You need more than just checks on individual builds, you need long term trend checking - 100 1% regressions are worse than a single 50% regression. Alex On Sun, Oct 20, 2013 at 11:24 AM, Tim Bell tim.b...@cern.ch wrote: ** ** From a user perspective, I want that a gate on changes which significantly degrade performance to be rejected. ** ** Tempest (and its associated CI) provide a current check on functionality. It is inline and understood. ** ** Let’s just add a set of benchmarks to Tempest which can validate that improved functionality does not significantly degrade performance. If we do not have this check, the users who are deploying early will be the ones whose services are affected which is not the long term direction. ** ** Thus, I ask, are there blocking items that would not permit Tempest to be extended to cover benchmarking and ensure changes which impact performance are picked up early ? ** ** Tim ** ** ** ** *From:* Boris Pavlovic [mailto:bpavlo...@mirantis.com] *Sent:* 20 October 2013 19:34 *To:* OpenStack Development Mailing List *Subject:* Re: [openstack-dev] Announce of Rally - benchmarking system for OpenStack ** ** Hi Sean, ** ** ** ** Honestly, there has been so much work done in Tempest with the stress tests and the scenario tests in this release, and a large growing community around those, that it doesn't make any sense to me that you put item #3 as a non Tempest thing. ** ** I really don't like to copy paste functionality that is already implemented, but I have some other ideas about benchmark engine, I would like to implement them and try as soon as possible, to determine what we actually need. It is much simpler to make such experiments in Rally, because there is a small community around it, and I don't care at this moment about backward comparability. ** ** When I determine all benchmark engine parameters (what I need). I will make one more deep investigation, to see how complex will be to implement the same in tempest. If it will be possible and not extra complex we will start implementing required functionality in tempest. And when tempest will be ready we will switch to it. ** ** ** ** Are you guys doing a summit session somewhere on this. ** ** There is a slot, but it is not approved http://summit.openstack.org/cfp/details/158 yet. Also there is a talk: http://openstacksummitnovember2013.sched.org/event/661ddc95f6b06ed3a634f12de09afa1d#.UmQITpTk9Z9 ** ** ** ** It also feels like the efforts around #4 would be much better served in the OpenStack community if they were integrated around testr and subunit so they could be reused in many contexts. ** ** I already tried to use pytest as a base and that was the biggest mistake.. ** ** ** ** ** ** I also think 1.b.3 is probably better done in the way the coverage extension was done for nova, something which is baked in and can be administratively turned on, not something which requires a hot patch to the system. ** ** ** ** I hope these patches will be merged. But you see there is a community deadlock here. You are not able to merge such patches in upstream until you make two things: 1) Get a real examples of usage (so e.g. with hot patching in Rally) 2) Approve that such changes don't impact on performance. (Rally) ** ** So we will prepare all patches, show live demonstration and approve that they don't impact on performance (especially when they are turned off) ;)* *** ** ** ** ** It's cool to have performance analysis tooling, but if it arrives in a way that doesn't integrate well with the rest of OpenStack, the impact is going to be far less than it could be. I'd like us to get the full bang for our buck out of efforts like this, especially if there is hope for it to graduate from stackforge into one of our standard toolkits. ** ** I don't understand the phrase doesn't integrate well with the rest of OpenStack ** ** 1. Project has classical OpenStack structure 2. We use all common code from oslo (db, localizations, oslo.config in future we are planing to use oslo.messaging) 3. As a base and first engine we decide to use DevStack 4. To verify deployments (we will use tempest asap) 5. In benchmark engine we are using only native OS python clients to make requests to
Re: [openstack-dev] Python-coverage: path change from /usr/bin/coverage to /usr/bin/python-coverage
It seems to me the much easier solution is to just always install coverage.py into a virtualenv, then we don't have to worry at all about operating-system politics. Alex On Wed, Oct 16, 2013 at 6:05 AM, Thomas Goirand z...@debian.org wrote: Hi there, It appears that in Debian, python-coverage provides the wrapper in /usr/bin/python-coverage. I tried to push the current maintainer to provide /usr/bin/coverage, but he doesn't agree. He believes that coverage is just too generic to be squatted by the python-coverage package. Robert Colins wrote that he sees it ok-ish if all of the OpenStack projects makes it so that we could also use /usr/bin/python-coverage. What is the view of others in the project? Could the path be checked, and then used, so that it works in every cases? Of course, the goal would be to avoid by hand patching in debian/patches whenever possible, because this is a major pain. Your thoughts? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] When will we stop adding new Python modules to requirements
Falcon was included as a result of Marconi moving from stackforge to being incubated. sphinxcontrib-programoutput doesn't appear to have been added at all, it's still under review: https://review.openstack.org/#/c/46325/ Alex On Sun, Sep 15, 2013 at 11:39 AM, Morgan Fainberg m...@metacloud.com wrote: Thomas, A couple if those appear to be managed by the OpenStack community (e.g. diskimage-builder), which likely should be included in either case. I would say if it is covered under the OpenStack proper list of git repos (e.g. https://github.com/openstack ) it should likely be included for packaging ?if it requires packaging). With that being said, I agree that it make sense for other (non-openstack) libraries to be added carefully late in the cycle. Perhaps the best would be to limit additions to prior to the release Feature-Freeze. Cheers, Morgan Fainberg On Sunday, September 15, 2013, Thomas Goirand wrote: Hi, Short version: the global-requirements.txt should be frozen asap because otherwise, packages wont be ready. Longer version: I'm getting worried that, even after Havana b3 is released, we are still getting some new Python modules added to the requirements repository. In Debian, every new package has to go through a review process, called the NEW queue. FTP masters review both the freeness of a package, the exactitude of debian/copyright, and the general packaging quality. Unfortunately, this review process can take a lot of time. At best, it is processed within a week (which is what happened for more than a year before November 2012), but in the worse case, it could take up to a month or 2 (this was the case up to the end of last summer, thanks to new manpower in the FTP team). So I need to point it out: adding new Python modules at the end of a release adds more risk that I will be missing some Python modules within the Debian archive when Havana will be released. I wouldn't have to write this mail if this was only a single module or something. Though that's not the case, we have 4 packages added this last week: - falcon - diskimage-builder - tripleo-image-elements - sphinxcontrib-programoutput I do understand that they might be absolutely needed, though it would be nice if additions to the global-requirements.txt file stopped at some point. And as far as I am concerned, the sooner the better, so that there's enough time to get the packages packaged, checked and tested, uploaded, approved by the FTP masters, and ready in time in Sid. Cheers, Thomas ___ 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 -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack + PyPy: Status and goals
The short answer is, PyPy has its own implementation of greenlets, https://bitbucket.org/pypy/pypy/src/default/lib_pypy/greenlet.py , this is built on top of a module called _continuation, http://doc.pypy.org/en/latest/stackless.html contains some of the details of how it works. Alex On Sun, Sep 15, 2013 at 2:43 PM, Joshua Harlow harlo...@yahoo-inc.comwrote: Cool, Are there any technical docs for how eventlet/greenlet work in PyPy, From my knowledge of greenlet its doing some pretty low level stuff that would seem hard to mirror in PyPy. https://github.com/python-greenlet/greenlet/blob/master/greenlet.c#L9 And the very platform specific stack switching functions @ https://github.com/python-greenlet/greenlet/tree/master/platform It would seem like greenlet is pretty tightly coupled to the cpython and its functionality. I'd like to know how it can operate in pypy without major modifications, maybe u know of such a documentation that explains this. I'd be interested in reading that at least (maybe others would like to also). :-) -Josh -- *From:* Alex Gaynor [alex.gay...@gmail.com] *Sent:* Tuesday, September 10, 2013 8:18 AM *To:* OpenStack Development Mailing List *Subject:* Re: [openstack-dev] OpenStack + PyPy: Status and goals Hi Roman, Yes eventlet works well on PyPy, both Marconi and Swift use it. Alex On Mon, Sep 9, 2013 at 10:15 PM, Roman Podolyaka rpodoly...@mirantis.comwrote: Hi Alex, That's really cool! I believe, performance is not the only benefit we can get from running OpenStack projects on PyPy. We can also improve the overall correctness of our code (as PyPy behaves differently with non-closed files, etc), just like compiling of your C/C++ app using different compilers can show hidden errors. And what about eventlet? Does it work well on PyPy? (as it is used in Nova, Neutron, etc) Thanks, Roman On Tue, Sep 10, 2013 at 12:28 AM, Alex Gaynor alex.gay...@gmail.comwrote: Hi all, Many of you have probably seen me send review requests in the last few weeks about adding PyPy support to various OpenStack projects. A few people were confused by these, so I wanted to fill everyone in on what I'm up to :) First, for those who aren't familiar with what PyPy is: PyPy is an implementation of the Python language which includes a high performance tracing just-in-time compiler and which is faster than CPython (the reference, and most widely deployed, implementation) on almost all workloads. The current status is: Two major projects work, both Marconi and Swift, Marconi is gating against PyPy already, Swift isn't yet since I needed to fix a few small PyPy bugs and those aren't in a release yet, expect it soon :) In terms of results, I've observed 30% performance improvements on GET workloads for Swift under PyPy vs. CPython (other workloads haven't been benchmarked tet). I believe the Marconi folks have also observed some performance wins, but I'll let them speak to that, I don't have the full details. Many python-clients projects are also working out of the box and gating: including novaclient, swiftclient, marconiclient, ceilometerclient, heatclient, and ironicclient! There's a few outstanding reviews to add PyPy gating for cinderclient, troveclient, and glanceclient. In terms of future direction: I'm going to continue to work on getting more projects running and gating against PyPy. Right now I'm focusing a lot of my attention on improving Swift performance, particularly under PyPy, but also under CPython. I'm hoping some day PyPy will be the default way to deploy OpenStack! If you're interested in getting your project running on PyPy, or looking at performance under it, please let me know, I'm always interested in helping! Thanks, Alex -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ 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 -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall
Re: [openstack-dev] OpenStack + PyPy: Status and goals
Hi Roman, Yes eventlet works well on PyPy, both Marconi and Swift use it. Alex On Mon, Sep 9, 2013 at 10:15 PM, Roman Podolyaka rpodoly...@mirantis.comwrote: Hi Alex, That's really cool! I believe, performance is not the only benefit we can get from running OpenStack projects on PyPy. We can also improve the overall correctness of our code (as PyPy behaves differently with non-closed files, etc), just like compiling of your C/C++ app using different compilers can show hidden errors. And what about eventlet? Does it work well on PyPy? (as it is used in Nova, Neutron, etc) Thanks, Roman On Tue, Sep 10, 2013 at 12:28 AM, Alex Gaynor alex.gay...@gmail.comwrote: Hi all, Many of you have probably seen me send review requests in the last few weeks about adding PyPy support to various OpenStack projects. A few people were confused by these, so I wanted to fill everyone in on what I'm up to :) First, for those who aren't familiar with what PyPy is: PyPy is an implementation of the Python language which includes a high performance tracing just-in-time compiler and which is faster than CPython (the reference, and most widely deployed, implementation) on almost all workloads. The current status is: Two major projects work, both Marconi and Swift, Marconi is gating against PyPy already, Swift isn't yet since I needed to fix a few small PyPy bugs and those aren't in a release yet, expect it soon :) In terms of results, I've observed 30% performance improvements on GET workloads for Swift under PyPy vs. CPython (other workloads haven't been benchmarked tet). I believe the Marconi folks have also observed some performance wins, but I'll let them speak to that, I don't have the full details. Many python-clients projects are also working out of the box and gating: including novaclient, swiftclient, marconiclient, ceilometerclient, heatclient, and ironicclient! There's a few outstanding reviews to add PyPy gating for cinderclient, troveclient, and glanceclient. In terms of future direction: I'm going to continue to work on getting more projects running and gating against PyPy. Right now I'm focusing a lot of my attention on improving Swift performance, particularly under PyPy, but also under CPython. I'm hoping some day PyPy will be the default way to deploy OpenStack! If you're interested in getting your project running on PyPy, or looking at performance under it, please let me know, I'm always interested in helping! Thanks, Alex -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ 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 -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-dev] Rechecks and Reverifies
I wonder if there's any sort of automation we can apply to this, for example having known rechecks have signatures and if a failure matches the signature it auto applies the recheck. Alex On Tue, Aug 27, 2013 at 9:18 AM, John Griffith john.griff...@solidfire.comwrote: This message has gone out a number of times but I want to stress (particularly to those submitting to Cinder) the importance of logging accurate recheck information. Please take the time to view the logs on a Jenkins fail before blindly entering recheck no bug. This is happening fairly frequently and quite frankly it does us no good if we don't look at the failure and capture things that might be going wrong in the tests. It's not hard, the CI team has put forth a good deal of effort to actually make it pretty easy. There's even a how to proceed link provided upon failure to walk you through the steps. The main thing is you have to look at the console output from your failed job. Also just FYI, pep8 and py26/27 failures are very rarely no bug they are usually a real problem in your patch. It would be good to pay particular attention to these before hitting recheck no bug. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-dev] Rechecks and Reverifies
Indeed, sorry for the distraction! Alex On Tue, Aug 27, 2013 at 11:23 AM, John Griffith john.griff...@solidfire.com wrote: On Tue, Aug 27, 2013 at 11:47 AM, Clark Boylan clark.boy...@gmail.comwrote: On Tue, Aug 27, 2013 at 10:15 AM, Clint Byrum cl...@fewbar.com wrote: Excerpts from John Griffith's message of 2013-08-27 09:42:37 -0700: On Tue, Aug 27, 2013 at 10:26 AM, Alex Gaynor alex.gay...@gmail.com wrote: I wonder if there's any sort of automation we can apply to this, for example having known rechecks have signatures and if a failure matches the signature it auto applies the recheck. I think we kinda already have that, the recheck list and the bug ID assigned to it no? Automatically scanning said list and doing the recheck automatically seems like overkill in my opinion. At some point human though/interaction is required and I don't think it's too much to ask a technical contributor to simply LOOK at the output from the test runs against their patches and help out a bit. At the very least if you didn't test your patch yourself and waited for Jenkins to tell you it's broken I would hope that a submitter would at least be motivated to fix their own issue that they introduced. It is worth thinking about though, because ask a technical contributor to simply LOOK is a lot more expensive than let a script confirm the failure and tack it onto the list for rechecks. Ubuntu has something like this going for all of their users and it is pretty impressive. Apport and/or whoopsie see crashes and look at the backtraces/coredumps/etc and then (with user permission) submit a signature to the backend. It is then analyzed and the result is this: http://errors.ubuntu.com/ Known false positives are shipped along side packages so that they do not produce noise, and known points of pain for debugging are eased by including logs and other things in bug reports when users are running the dev release. This results in a much better metric for what bugs to address first. IIRC update-manager also checks in with a URL that is informed partially by this data about whether or not to update packages, so if there is a high fail rate early on, the server side will basically signal update-manager don't update right now. I'd love to see our CI system enhanced to do all of the pattern matching to group failures by common patterns, and then when a technical contributor looks at these groups they have tons of data points to _fix_ the problem rather than just spending their precious time identifying it. The point of the recheck system, IMHO, isn't to make running rechecks easier, it is to find and fix bugs. This is definitely worth thinking about and we had a session on dealing with CI logs to do interesting things like update bugs and handle rechecks automatically at the Havana summit[0]. Since then we have built a logstash + elasticsearch system[1] that filters many of our test logs and indexes a subset of what was filtered (typically anything with a log level greater than DEBUG). Building this system is step one in being able to detect anomalous logs, update bugs, and potentially perform automatic rechecks with the appropriate bug. Progress has been somewhat slow, but the current setup should be mostly stable. If anyone is interested in poking at these tools to do interesting automation with them feel free to bug the Infra team. That said, we won't have something super automagic like that before the end of Havana making John's point an important one. If previous release feature freezes are any indication we will continue to put more pressure on the CI system as we near Havana's feature freeze. Any unneeded rechecks or reverifies can potentially slow the whole process down for everyone. We should be running as many tests as possible locally before pushing to Gerrit (this is as simple as running `tox`) and making a best effort to identify the bugs that cause failures when performing rechecks or reverifies. [0] https://etherpad.openstack.org/havana-ci-logging [1] http://ci.openstack.org/logstash.html Thank you, Clark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The automation ideas are great, no argument there didn't mean to imply they weren't or discount them. Just don't want the intent of the message to get lost in all the things we could do going forward. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9
Re: [openstack-dev] proposing Alex Gaynor for core on openstack/requirements
Thanks everyone, I look forward to continuing to help out! Alex On Tue, Aug 20, 2013 at 9:49 AM, Doug Hellmann doug.hellm...@dreamhost.comwrote: Without any objections, I've added Alex Gaynor to the requirements-core team. Welcome, Alex! On Sat, Aug 17, 2013 at 2:46 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2013-08-16 11:04:14 -0400 (-0400), Doug Hellmann wrote: I'd like to propose Alex Gaynor for core status on the requirements project. [...] Agreed, I for one welcome his continued assistance. -- 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 -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Swift, netifaces, PyPy, and cffi
So, in what can only be described as extremely embarrassing and wow, I thought I knew how to use a computer: netifaces appears to work ok under PyPy! I could have sworn I'd tested it, but apparently not. So, this is no longer a high priority item for me to get swift on pypy (in fact, +/- eventlet and pypy releases, the test suite at least all passes!). I still think long term ditching netifaces is a good idea since it doesn't really appear to be maintained, but that's a different issue. Since code churn scares me I'm going to stop really pursuing this, the patch will always be there if anyone else is excited about this, and maybe someday I'll get the round tuits to do it myself :) Alex On Wed, Aug 14, 2013 at 5:17 PM, Vishvananda Ishaya vishvana...@gmail.comwrote: On Aug 14, 2013, at 11:12 AM, Jarret Raim jarret.r...@rackspace.com wrote: I vote for including cffi. We are going to use a cffi lib as part of Barbican (key management) anyway, so I'd like to see wider acceptance. Jarret +1 cffi rocks Vish From: Alex Gaynor alex.gay...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Wednesday, August 14, 2013 12:12 PM To: openst...@nemebean.com openst...@nemebean.com, OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Swift, netifaces, PyPy, and cffi I just chatted with the Python product owner at Red Hat, he says this is going to make it's way to the next step later today (this past weekend was a Fedora conference), so this should be happening soon. Joe: Yup, I'm familiar with that piece (I had lunch with Vish the other week and he's the one who suggested Swift as the best place to get started with OpenStack + PyPy). For those who don't know I'm one of the core developers of PyPy :) Alex On Wed, Aug 14, 2013 at 9:24 AM, Ben Nemec openst...@nemebean.com wrote: On 2013-08-13 16:58, Alex Gaynor wrote: One of the issues that came up in this review however, is that cffi is not packaged in the most recent Ubuntu LTS (and likely other distributions), although it is available in raring, and in a PPA (http://packages.ubuntu.com/**raring/python-cffihttp://packages.ubuntu.com/raring/python-cffi[2] nd https://launchpad.net/~**pypy/+archive/ppa?field.** series_filter=precisehttps://launchpad.net/~pypy/+archive/ppa?field.series_filter=precise [3] respectively). As a result of this, we wanted to get some feedback on which direction is best to go: a) cffi-only approach, this is obviously the simplest approach, and works everywhere (assuming you can install a PPA, use pip, or similar for cffi) b) wait until the next LTS to move to this approach (requires waiting until 2014 for PyPy support) c) Support using either netifaces or cffi: most complex, and most code, plus one or the other dependencies aren't well supported by most tools as far as I know. It doesn't appear to me that this is available for RHEL yet, although it looks like they're working on it: https://admin.fedoraproject.** org/updates/python-cffi-0.6-4.**el6https://admin.fedoraproject.org/updates/python-cffi-0.6-4.el6 That's also going to need to happen before we can do this, I think. -Ben __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ 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 -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gate breakage process - Let's fix! (related but not specific to neutron)
I'd strongly agree with that, a project must always be gated by any tests for it, even if they don't gate for other projects. I'd also argue that any time there's a non-gating test (for any project) it needs a formal explanation of why it's not gating yet, what the plan to get it to gating is, and on what timeframe it's expected to be. Alex On Fri, Aug 16, 2013 at 11:25 AM, Maru Newby ma...@redhat.com wrote: Neutron has been in and out of the gate for the better part of the past month, and it didn't slow the pace of development one bit. Most Neutron developers kept on working as if nothing was wrong, blithely merging changes with no guarantees that they weren't introducing new breakage. New bugs were indeed merged, greatly increasing the time and effort required to get Neutron back in the gate. I don't think this is sustainable, and I'd like to make a suggestion for how to minimize the impact of gate breakage. For the record, I don't think consistent gate breakage in one project should be allowed to hold up the development of other projects. The current approach of skipping tests or otherwise making a given job non-voting for innocent projects should continue. It is arguably worth taking the risk of relaxing gating for those innocent projects rather than halting development unnecessarily. However, I don't think it is a good idea to relax a broken gate for the offending project. So if a broken job/test is clearly Neutron related, it should continue to gate Neutron, effectively preventing merges until the problem is fixed. This would both raise the visibility of breakage beyond the person responsible for fixing it, and prevent additional breakage from slipping past were the gating to be relaxed. Thoughts? m. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Swift, netifaces, PyPy, and cffi
I just chatted with the Python product owner at Red Hat, he says this is going to make it's way to the next step later today (this past weekend was a Fedora conference), so this should be happening soon. Joe: Yup, I'm familiar with that piece (I had lunch with Vish the other week and he's the one who suggested Swift as the best place to get started with OpenStack + PyPy). For those who don't know I'm one of the core developers of PyPy :) Alex On Wed, Aug 14, 2013 at 9:24 AM, Ben Nemec openst...@nemebean.com wrote: On 2013-08-13 16:58, Alex Gaynor wrote: One of the issues that came up in this review however, is that cffi is not packaged in the most recent Ubuntu LTS (and likely other distributions), although it is available in raring, and in a PPA (http://packages.ubuntu.com/**raring/python-cffihttp://packages.ubuntu.com/raring/python-cffi[2] nd https://launchpad.net/~**pypy/+archive/ppa?field.** series_filter=precisehttps://launchpad.net/~pypy/+archive/ppa?field.series_filter=precise [3] respectively). As a result of this, we wanted to get some feedback on which direction is best to go: a) cffi-only approach, this is obviously the simplest approach, and works everywhere (assuming you can install a PPA, use pip, or similar for cffi) b) wait until the next LTS to move to this approach (requires waiting until 2014 for PyPy support) c) Support using either netifaces or cffi: most complex, and most code, plus one or the other dependencies aren't well supported by most tools as far as I know. It doesn't appear to me that this is available for RHEL yet, although it looks like they're working on it: https://admin.fedoraproject.** org/updates/python-cffi-0.6-4.**el6https://admin.fedoraproject.org/updates/python-cffi-0.6-4.el6 That's also going to need to happen before we can do this, I think. -Ben __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Swift, netifaces, PyPy, and cffi
Hi all, (This references this changeset: https://review.openstack.org/#/c/38415/) One of the goals I've been working at has been getting swift running on PyPy (and from there, the rest of OpenStack). The last blocking issue in swift is that it currently uses netifaces, which is a C-extension that doesn't on PyPy. I've proposed to replace this dependency with a cffi based binding to the system. For those not familiar, cffi is a tool for binding to C libraries, similar to ctypes (in the stdlib), except more expressive, less error prone, and faster; some of our downstream dependencies already use it. One of the issues that came up in this review however, is that cffi is not packaged in the most recent Ubuntu LTS (and likely other distributions), although it is available in raring, and in a PPA ( http://packages.ubuntu.com/raring/python-cffi and https://launchpad.net/~pypy/+archive/ppa?field.series_filter=preciserespectively). As a result of this, we wanted to get some feedback on which direction is best to go: a) cffi-only approach, this is obviously the simplest approach, and works everywhere (assuming you can install a PPA, use pip, or similar for cffi) b) wait until the next LTS to move to this approach (requires waiting until 2014 for PyPy support) c) Support using either netifaces or cffi: most complex, and most code, plus one or the other dependencies aren't well supported by most tools as far as I know. Thoughts? Alex -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302
I'd favor weakening or removing this requirement. Besides google I've never seen any other python project which enforced this standard, and I think it's a very weak heuristic for readability. Alex On Mon, Aug 5, 2013 at 7:26 PM, Robert Collins robe...@robertcollins.netwrote: I wanted to get a temperature reading from everyone on this style guideline. My view on it is that it's a useful heuristic but shouldn't be a golden rule applied everywhere. Things like matches are designed to be used as a dsl: self.assertThat(foo, Or(Equals(1), Equals(2))) rather than what H302 enforces: self.assertThat(foo, matchers.Or(matchers.Equals(1), matchers.Equals(2))) Further, conflicting module names become harder to manage, when one could import just the thing. Some arguments for requiring imports of modules: - makes the source of symbols obvious - Actually, it has no impact on that as the import is still present and clear in the file. import * would obfuscate things, but I'm not arguing for that. - and package/module names can (and are!) still ambiguous. Like 'test.' - whats that? - consult the imports. - makes mocking more reliable - This is arguably the case, but it's a mirage: it isn't a complete solution because modules still need to be mocked at every place they are dereferenced : only import modules helps to the extent that one never mocks modules. Either way this failure mode of mocking is usually very obvious IME : but keeping the rule as a recommendation, *particularly* when crossing layers to static resources is a good idea. - It's in the Google Python style guide ( http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Imports#Imports ) - shrug :) What I'd like us to do is weaken it from a MUST to a MAY, unless noone cares about it at all, in which case lets just turn it off entirely. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Usage of mox through out the Openstack project.
I think moving towards mock is a better long term strategy: a) I don't you're correct that it's the most familiar for most python developers. By PyPi installs (A TERRIBLE METRIC, but it's all we have). Mock has 24k in the last week, mox has 3.5k b) mock is a part of the standard library starting with python 3.3, this will lead to even more adoption. Alex On Wed, Jul 24, 2013 at 11:12 AM, Chuck Short chuck.sh...@canonical.comwrote: Hi, The use of mox (https://pypi.python.org/pypi/mox/0.5.3) across the test suites in the Openstack project is quite extensive. This is probably due to the fact that it is the most familiar mocking object framework for most python developers. However there is big drawback with using mox across all of the OpenStack projects is that it is not python3 compatible. This makes python3 compliance problematic because we want the test suites to be compatible as well. While thinking about this problem for a while now, while helping porting OpenStack over to python3 there is a couple of options that as a project can do as a whole: 1. Change mox usage to more python3 friendly such as mock. ( https://pypi.python.org/pypi/mock/1.0.1). However this will cause alot of code churn in the projects as we move away from mox to mock. 2. Use the python3 fork called pymox (https://github.com/emonty/pymox). This project has reasonable compatibility with mox and is python3 compatible. Using this option causes less code churn. IMHO this would be the better option. I would like to hear peoples opinion on this. Thanks chuck ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pip requirements externally host (evil evil stab stab stab)
As a heads up I filed bugs with each of these projects (with the exception of netifaces, which doesn't appear to have a tracker). The dnspython maintainer has already uploaded the package to PyPi and disabled scraping! Alex On Fri, Jul 19, 2013 at 8:04 PM, Monty Taylor mord...@inaugust.com wrote: Hey guys! PyPI is moving towards the world of getting people to stop hosting stuff via external links. It's been bad for us in the past and one of the reasons for the existence of our mirror. pip 1.4 has an option to disallow following external links, and in 1.5 it's going to be the default behavior. Looking forward, we have 5 pip packages that host their stuff externally. If we have any pull with their authors, we should get them to actually upload stuff to pypi. If we don't, we should strongly consider our use of these packages. As soon as pip 1.4 comes out, I would like to moving forward restrict the addition of NEW requirements that do not host on pypi. (all 5 of these host insecurely as well, fwiw) The culprits are: dnspython,lockfile,netifaces,psutil,pysendfile ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] pip requirements externally host (evil evil stab stab stab)
netifaces is also used in swift for the whataremyips function. (Personaly I'd love to replace that as it doesn't work on PyPy, but that's a rather different conversation :)) Alex On Sat, Jul 20, 2013 at 9:10 AM, Salvatore Orlando sorla...@nicira.comwrote: I reckon the netifaces package is only used in Neutron's Ryu plugin. At a first glance, it should be possible to replace its current usage with the iplib module which has been developed within neutron itself. Unless we hear otherwise from contributors to the Ryu plugin it is my opinion that we should move towards replacing netifaces. Salvatore On 19 July 2013 20:04, Monty Taylor mord...@inaugust.com wrote: Hey guys! PyPI is moving towards the world of getting people to stop hosting stuff via external links. It's been bad for us in the past and one of the reasons for the existence of our mirror. pip 1.4 has an option to disallow following external links, and in 1.5 it's going to be the default behavior. Looking forward, we have 5 pip packages that host their stuff externally. If we have any pull with their authors, we should get them to actually upload stuff to pypi. If we don't, we should strongly consider our use of these packages. As soon as pip 1.4 comes out, I would like to moving forward restrict the addition of NEW requirements that do not host on pypi. (all 5 of these host insecurely as well, fwiw) The culprits are: dnspython,lockfile,netifaces,psutil,pysendfile ___ 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 -- I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall (summarizing Voltaire) The people's good is the highest law. -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
