2018-04-13 15:07 GMT+02:00 Thomas Goirand :
> BTW, any progress on upstream Swift WRT Py3 support?
There is a voting Python 3.4 gate which runs 902 unit tests. The
Python 2.7 gate runs 5,902 unit tests. I compute that 15% of unit
tests pass on Python 3.4.
I tested locally with Python 3.5 (tox -e
2018-04-13 14:48 GMT+02:00 Thomas Goirand :
> On 03/17/2018 09:34 AM, Emilien Macchi wrote:
>> ## Challenges
>>
>> - Some services aren't fully Python 3
>
> To my experience switching everything to Py3 in Debian, the only issues
> were:
>
> - manila-ui
> - networking-mlnx
What about swift?
Victor
Adding the charset sounds like a good practice, especially in Keystone
which is security sensitive. See this old Python vulnerability:
http://python-security.readthedocs.io/vuln/cve-2011-4940_simplehttpserver_utf-7.html
"The list_directory() function in Lib/SimpleHTTPServer.py in
SimpleHTTPSer
Le 17/01/2017 à 17:36, Sean Dague a écrit :
When putting the cli interface on it, I discovered python3's argparse
has subparsers built in. This makes building up the cli much easier, and
removes pulling in a dependency for that. (Currently the only item in
requirements.txt is pbr). This is useful
+1 from me.
Victor
Le 03/10/2016 à 19:40, Joshua Harlow a écrit :
Greetings all stackers,
I propose that we add Gevorg Davoian[1] to the oslo-core[2] team.
Gevorg has been actively contributing to oslo for a while now, both in
helping make oslo better via code contribution(s) and by helping w
+1 from me.
Victor
Le 03/10/2016 à 19:42, Joshua Harlow a écrit :
Greetings all stackers,
I propose that we add Oleksii Zamiatin[1] to the oslo-core[2] team.
Oleksii has been actively contributing to oslo for a while now, both in
helping make oslo better via code contribution(s) and by helpin
Hi,
Le 30/08/2016 à 16:39, Antoni Segura Puimedon a écrit :
a) Work with the OpenStack distributions to ensure python3.5 support is
reached soon for Kuryr and its dependencies (some listed below):
* babel
* oslo.concurrency
* oslo.config
* oslo.log
* oslo.utils
* pbr
* pyroute2
Hi,
Le 13/07/2016 à 21:17, Denis Makogon a écrit :
I have free capacity to work on porting code to Py3. So, if any PTL is
running out of team capacity i can help to work on project to enable Py3
support.
If you would like to help, you can try to run functional tests on
DevStack. Begin with pr
Le 04/07/2016 à 07:59, Denis Makogon a écrit :
Then let it run for a day or two in our CI, discuss with neutron team,
and send a patch for project-config to change the setup,
Can confirm that nova, glance, cinder, heat clients are py35 compatible.
tox.ini of Nova, Swift and Trove need
Hi,
I'm working on a new Python 3 patches to port the "last" Nova unit
tests. For example, my current patch serie ports 1,107 more unit tests
(76% => 84%). Changes should be "quite simple" but I need your help to
review them! My serie of 10 patches starts at:
https://review.openstack.org/#/c/
Le 22/06/2016 à 09:18, Victor Stinner a écrit :
Current status: only 3 projects are not ported yet to Python 3:
* nova (76% done)
* trove (42%)
* swift (0%)
If you want to help, please review my patches! I sent patches to these
projects.
Nova:
https://review.openstack.org/#/c/332686
Le 23/06/2016 à 23:04, Thomas Goirand a écrit :
Just think about it for a while. If we get Nova to work with Py3, and
everything else is working, including all functional tests in Tempest,
Hum, that's a long list of expectations :-)
then after Otaca, we could even start to *REMOVE* Py2 suppo
Le 23/06/2016 à 18:11, Doug Hellmann a écrit :
I'd like for the community to set a goal for Ocata to have Python
3 functional tests running for all projects.
We can already experiment functional tests right now ;-) I expect to get
many small issues in all projects, but it may take time to fix
Le 22/06/2016 à 10:49, Thomas Goirand a écrit :
Do you think it looks like possible to have Nova ported to Py3 during
the Newton cycle?
It doesn't depend on me: I'm sending patches, and then I have to wait
for reviews. The question is more how to accelerate reviews.
Right now, I'm splitting
Hi,
Current status: only 3 projects are not ported yet to Python 3:
* nova (76% done)
* trove (42%)
* swift (0%)
https://wiki.openstack.org/wiki/Python3
Number of projects already ported:
* 19 Oslo Libraries
* 4 Development Tools
* 22 OpenStack Clients
* 6 OpenStack Libraries (os-brick, ta
Le 21/05/2016 à 05:58, Morgan Fainberg a écrit :
We've gone through all of our test cases and all of our code base. At
this point Keystone is no longer skipping any of the tests (which do
tend to test the entire request stack) and we are properly gating on
being Python3.4 compatible.
By the way
Le 16/05/2016 16:12, Peter Stachowski a écrit :
We're aware that there are ways to mock (and un-mock) correctly.
We're trying to make sure that all our new test code follows those
patterns. We also decided that it wouldn't make sense to change all
the working tests to use the 'right' methods as
Le 16/05/2016 16:12, Peter Stachowski a écrit :
Amrith is right though - python34 is *much* slower running this check
(and somewhat in general) than python27. Maybe that doesn't
translate into real-world performance data, but it has made me a bit
nervous nonetheless.
IMHO we should look more c
Le 09/05/2016 16:16, Peter Stachowski a écrit :
Hi Amrith,
We’ve had a lot of ‘new’ tests enabled for py34 in the last week – from
your results you can see it’s running 6x the number of tests (although
it’s taking 8.5x as long). It looks like python3 isn’t as fast as
python2.7? If so, we may h
Le 16/05/2016 13:52, Amrith Kumar a écrit :
IMHO the strange mock detector code must be removed. It is very
slow and I don't understand its purpose.
[amrith] It serves and has served a very useful purpose and that is
to detect bad tests where code has (and we've had lots of trouble
with this) e
Hi,
Le 09/05/2016 16:38, Amrith Kumar a écrit :
So I’m able to run the py34 tests in about 10s if I run the dangling
mock detector with a depth of 0 or 1.
IMHO the strange mock detector code must be removed. It is very slow and
I don't understand its purpose.
The mock module has a nice stop
Le 13/04/2016 22:54, Julien Danjou a écrit :
There's a bunch of projects that have no intention of using
oslo.context, so depending and referring to it by default is something
I'd love to fade away.
It looks like Oslo has an identity crisis :-)
Basically the question looks like: should we make
Le 01/04/2016 03:12, Assaf Muller a écrit :
2) Now, transform yourself six to twelve months in the future. We now
face a new problem. (...) I hereby propose that we remove the
tests. (...) Needless to say, my
proposal keeps pep8 in place. We all know how important a consistent
style is.
The goo
Le 08/03/2016 22:22, gordon chung a écrit :
it seems like the main reason there are so many projects leveraging WSME
is because everyone is just using Ironic or Ceilometer as the starting
point for their APIs. can we officially say to all new projects who plan
on copying API logic of Ironic et al
Hi,
I just wrote an article "Status of Python 3 in OpenStack Mitaka":
http://blogs.rdoproject.org/7894/status-of-python-3-in-openstack-mitaka
Summary:
* 13 services were ported to Python 3 during the Mitaka cycle: Cinder,
Glance, Heat, Horizon, etc.
* 9 services still need to be ported
* Next
Le 03/03/2016 13:05, Flavio Percoco a écrit :
Thanks for all your hard work as an Oslo PTL. You did amazing and I
think you'd
do an awesome mentor for other folks as well. It was an honor to have
you as a
PTL and I look forward to keep working with you as an Oslo contributor.
I concur with Flav
;AssertionError: Cannot switch to MAINLOOP from MAINLOOP" error"
Victor
Le 18/02/2016 11:05, Victor Stinner a écrit :
Hi,
Le 17/02/2016 19:29, no-re...@openstack.org a écrit :
> We are chuffed to announce the release of:
>
> oslo.service 0.9.1: oslo.service library
>
Le 18/02/2016 14:15, Amrith Kumar a écrit :
Let's definitely discuss this again once you have all the changes that you feel
should be merged for Mitaka ready.
I don't like working on long patch series. In my experience, after more
than 4 patches, it's more expensive to maintain the patch seri
Hi,
When I began to work on porting Trove to Python 3, I was blocked by
MySQL-Python which is not compatible with Python 3. I tried a big change
replacing MySQL-Python with PyMySQL, since other OpenStack services also
moved to PyMySQL. But tests fail and I'm unable to fix them :-/
https://rev
Hi,
Le 17/02/2016 19:29, no-re...@openstack.org a écrit :
> We are chuffed to announce the release of:
>
> oslo.service 0.9.1: oslo.service library
> (...)
>
> Changes in oslo.service 0.9.0..0.9.1
>
>
> 8b6e2f6 Fix race condition on handling signals
> eb1a4aa
Le 17/02/2016 13:43, Henry Gessau a écrit :
And it looks like eventlet 0.18.3 breaks neutron:
https://bugs.launchpad.net/neutron/+bug/1546506
2 releases, 2 regressions in OpenStack. Should we cap eventlet version?
The requirement bot can produce patches to update eventlet, patches
which would
Le 12/02/2016 15:12, Ian Cordasco a écrit :
Just to interject here, RFC 2616 is the one you're talking about. That
encoding requirement was dropped when HTTP/1.1 was updated in the
7230-7235 RFCs. (...)
Where VCHAR is any visible US ASCII character. So while UTF-8 is still
a bad idea for the head
Le 12/02/2016 13:01, Sean Dague a écrit :
OpenStack is wildly inconsistent in it's use of tenant vs. project.
Yeah, it's time to find a 3rd term to avoid confusion! ;-)
Victor
__
OpenStack Development Mailing List (not fo
Hi,
Le 08/02/2016 14:42, Victor Stinner a écrit :
> https://review.openstack.org/#/c/237019/
Nice, this one was merged!
https://review.openstack.org/#/c/237027/
https://review.openstack.org/#/c/236998/
These two changes look to be blocked by encodings issues. Tim Burke,
Samuel Merritt
Hi,
I asked eventlet dev to *not* remove a release from PyPI before they did
it, but they ignored me and removed 0.18.0 and 0.18.1 releases from PyPI :-(
0.18.0 fixed a bug in Python 3:
https://github.com/eventlet/eventlet/issues/274
But 0.18.0 introduced a regression on Python 3 in WSGI:
htt
small, but the work will get larger as you go.
You're right about needing the voting gate job. That should be the first
priority for py3 work.
--John
On 30 Oct 2015, at 12:47, Victor Stinner wrote:
Hi,
We talked about Python 3 with Christian Schwede, Alistair Coles, Samuel Meritt
(I added [all] to the topic)
Hi,
Le 02/02/2016 17:20, dava...@gmail.com a écrit :
We are thrilled to announce the release of:
oslo.context 2.0.0: Oslo Context library
(...)
4a8a1df Fix request_id type on Python 3: use text (Unicode)
This change is a deliberate incompatible change in the API,
+1 for me
Le 28/01/2016 16:25, Davanum Srinivas a écrit :
Team,
Dmitry has been focused solely on the Pika Driver this cycle:
http://stackalytics.com/?user_id=dukhlov&metric=commits
Now that we have Pika driver in master, i'd like to invite Dmitry to
continue his work on all of Oslo.Messaging
(I changed the title to stop hijacking the Oslo thread.)
Hi,
Le 30/01/2016 22:25, Julien Danjou a écrit :
> (...) And it's easier/faster to fix with a larger team than a few.
> Which mean inclusion. Which mean openness.
While I think that Julien is a little bit rude and his email is stongly
op
Thanks for investigating the tabulate option :-)
Victor
Le 26/01/2016 02:25, Joshua Harlow a écrit :
As far as the other option (using tabulate):
https://bitbucket.org/astanin/python-tabulate/pull-requests/25/
That was a (very very basic) POC for a potential compatibility layer,
The author (
Hi,
Oops, I feel guilty, I wrote the patch which introduced the regression
:-/ My patch fixes a bug on Python 3: "sock.makefile('rb').readline()
doesn't handle blocking errors correctly"
https://github.com/eventlet/eventlet/issues/274
I was relying on the eventlet test suite, but it looks lik
Hi,
What are the issues? Is there a list of issues somewhere?
Victor
Le 13/01/2016 03:07, Thomas Goirand a écrit :
Hi,
Just a quick notice for those not following developments in Debian.
Python 3.5 is now the default Python 3 interpreter in Debian Unstable,
and when the transition will be fin
Le 11/01/2016 10:37, Thierry Carrez a écrit :
Joshua Harlow wrote:
[...]
So I'd def help keep prettytable going, of course another option is to
move to https://pypi.python.org/pypi/tabulate (which does seem active
and/or maintained); tabulate provides pretty much the same thing
(actually more ta
Le 16/12/2015 20:33, Davanum Srinivas a écrit :
Brant,
I am ok either way, guess the alternative was to add keystone-core
directly to the oslo.policy core group (can't check right now).
The name is very possibly going to create confusion
-- Dims
I heard some people consider that "OpenStack"
Hi,
Le 04/12/2015 05:12, Eric K a écrit :
Congress can finally pass python34 gating.
Here’s the last patch needed to make it happen.
https://review.openstack.org/#/c/253298/
Great job :-) Congrats.
I see that antlr3 was ported to Python 3 in the commit
0576d774a49dd310970974d0c881e8bd4915c2
All informations on Python 3 are on the wiki:
https://wiki.openstack.org/wiki/Python3
You may also join the IRC channel on Freenode: #openstack-python3
Victor
Le 25/11/2015 03:33, Eric Kao a écrit :
Hi all,
I’ve been using the python-future library for Python 3 porting and want
to see what pe
Hi,
I'm porting OpenStack code to Python 3 for two years. I'm happy with
six. It has been adopted by all OpenStack projects which are being
ported to (or have been ported to) Python 3. It was discussed to use
python-future in Swift, but Swift is now using six too.
I wrote a tool to port an O
Hi,
The next oslo.context release including the following change (still
under review) might break the voting Python 3 gate of your project:
https://review.openstack.org/#/c/250731/
Please try to run Python 3 tests of your project with this change. I
already ran the tests on Python 3 of th
Hi,
I noticed that ChangBo Guo (aka gcb) is very active in various Oslo
projects, to write patches but also to review patches written by others.
He attend Oslo meetings, welcome reviews, etc. It's a pleasure to work
with him.
To accelerate the Oslo development, I propose to invite ChangBo to
Hi,
Would it be possible to use the "extra dependencies" thing in setup.cfg?
Robert Collins started a similar change for Oslo DB for make DB drivers
optional:
https://review.openstack.org/#/c/184328/
Sadly, this change was not merged yet.
@Robert: any progress on this change?
It would allow
Le 16/11/2015 08:33, Kekane, Abhishek a écrit :
Hi,
As apiclient is now removed from oslo-incubator, to proceed with
request-id spec [1] I have two options in mind,
1.Use keystoneauth1 + cliff in all python-clients (add request-id
support in cliff library)
2.apiclient code is available in all
Le 10/11/2015 15:33, Davanum Srinivas a écrit :
+1 Victor.
Ok thanks for the confirmation. The comment disturbed me a lot :-D
Here is a simple change to remove the comment:
https://review.openstack.org/243630
Victor
__
O
Hi,
In oslo_config/cfg.py, there is a main Opt class which takes an optional
type parameter (default is oslo_config.types.String). But there is also
a long list of XxxOpt classes: StrOpt, BoolOpt, FloatOpt, ListOpt,
IPOpt, etc. Recently I saw *new* classes added with the "kept for
backward-co
Le 10/11/2015 14:01, Davanum Srinivas a écrit :
That's exactly what i want as well. We should just let whoever has
copies to do whatever they want with them and drop our oversight of
it. Since they are mature and haven't been touched for a while, i
really don't see the need to take care of them.
Hi,
Le 10/11/2015 07:29, Kekane, Abhishek a écrit :
We have done extensive analysis to figure out the differences of usages of
different oslo-incubator/openstack/common/apiclient modules used in the
respective Openstack python client libraries and added all our
observations in the google spreads
Hi,
At Tokyo, we discussed quickly what to do with cliutils.py of
oslo-incubator, but for me the plan is not really concrete.
https://etherpad.openstack.org/p/mitaka-oslo-incubator-cleanup
I don't like dims' suggestion to move code inside clients, it means
duplicating 280 lines of python in
Le 02/11/2015 19:40, Brant Knudson a écrit :
(...) by typing something like:
$ bandit-conf-generator --disable try_except_pass --out bandit.yaml
oslo.messaging ~/openstack/bandit/bandit/config/bandit.yaml
(...) we should have a config file for bandit-conf-generator...
but then why not
Hi,
We talked about Python 3 with Christian Schwede, Alistair Coles, Samuel
Meritt, Jaivish Kothari and others (sorry, I don't recall all names :-/)
during Swift contributor meetup. It looks like we had an agreement on
how to add Python 3 support to Swift. The plan is:
1) Fix the gate-swift-
Le 15/10/2015 17:54, Joshua Harlow a écrit :
I had this problem with deprecation versioning (the debtcollector
library functions take a version="XYZ", removal_version="ABC" params,
see
http://docs.openstack.org/developer/debtcollector/examples.html#further-customizing-the-emitted-messages)
and it
Le 15/10/2015 16:34, Brant Knudson a écrit :
Submitters don't know what release their change is going to get into.
They might submit the review when version 1.1.0 is current so they mark
it with added in 1.2.0, but then the change doesn't get merged until
after 1.4.0 is tagged. Also, the submitte
Le 15/10/2015 12:52, Victor Stinner a écrit :
I started to do this for the oslo.config library:
https://review.openstack.org/#/c/235232/
More changes.
oslo.concurrency:
https://review.openstack.org/#/c/235416/
oslo.serialization:
https://review.openstack.org/#/c/235297/
oslo.utils:
https
Hi,
I propose that changes must now be documented in Oslo libraries. If a
change is not documented, it must *not* be approved.
IMHO it's very important to document all changes. Otherwise, it becomes
really hard to guess if a specific parameter or a specific function can
be used just by readi
Le 12/10/2015 10:43, Victor Stinner a écrit :
WebOb 1.5 was released yesterday. test_misc of Cinder starts failing
with this release. I wrote this simple fix which should be enough to
repair it:
https://review.openstack.org/233528
"Fix test_misc for WebOb 1.5"
FYI my fix was merged
Hi,
WebOb 1.5 was released yesterday. test_misc of Cinder starts failing
with this release. I wrote this simple fix which should be enough to
repair it:
https://review.openstack.org/233528
"Fix test_misc for WebOb 1.5"
class ConvertedException(webob.exc.WSGIHTTPException):
-def __init__
Hi,
Le 09/10/2015 12:12, vishal yadav a écrit :
However I was just checking if you considered using 2to3. I can
understand that translation using this tool might not cover every area
in the code more specifically custom/3rd party libraries (non-standard
python libraries) but IMO it can do fixer
Hi,
Good news, we made good progress last weeks on porting Swift to Python
3, a few changes were merged and all dependencies now work on Python 3.
We only need two more simple changes to have a working pyhon34 check job:
* "py3: Update pbr and dnspython requirements"
https://review.openstac
Hi,
Le 06/10/2015 16:36, Flavio Percoco a écrit :
Not so long ago, Erno started a thread[0] in this list to discuss the
abandon policies for patches that haven't been updated in Glance.
(...)
1) Lets do this on patches that haven't had any activity in the last 2
months. This adds one more month
Hi,
Le 01/10/2015 15:50, Nikolay Makhotkin a écrit :
In Mistral, we are trying to fix the codebase for supporting python3,
but we are not able to do this since we faced issue with pecan library.
If you want to see the details, see this traceback - [1].
I tried to run Mistral tests on Python 3
Le 25/09/2015 17:00, Julien Danjou a écrit :
If we wanted to enforce that, we would just have to write a bot setting
-1 automatically. I'm getting tired of seeing people doing bots' jobs in
Gerrit.
It may also help to enhance "git review -s" to install a local
post-commit hook to warn if the c
+1 for Brant
Victor
Le 24/09/2015 19:12, Doug Hellmann a écrit :
Oslo team,
I am nominating Brant Knudson for Oslo core.
As liaison from the Keystone team Brant has participated in meetings,
summit sessions, and other discussions at a level higher than some
of our own core team members. He i
Hi,
I'm porting Cinder to Python 3. There are discussions on my patches to
decide how to link my changes to the cinder-python3 blueprint (syntax of
the "Blueprint cinder-python3" line).
Mike Perez completed the blueprint on 2015-08-15. I don't understand
why, the port is incomplete. I'm stil
Le 29/07/2015 18:12, Clay Gerrard a écrit :
I agree an error message is better than breaking for insane reasons.
But... maybe as an aside... what about not breaking?
Well, yes, but *who* wants to do that?
Old versions of setuptoolsl, pip and pbr have a lot of issues. It will
be a nightmare t
Le 29/07/2015 10:27, Robert Collins a écrit :
Similar to pbr, we have a minimum version of setuptools required to
consistently install things in OpenStack. Right now thats 17.1.
However, we don't declare a setup_requires version for it.
I think we should.
If it's possible to explicit the mini
Hi,
On 27/07/2015 12:35, Roman Vasilets wrote:
Hi, just what to share with you. Rally project also have voting py34
jobs. Thank you.
Cool! I don't know if Rally port the Python 3 is complete or not, so I
wrote "work in progress". Please update the wiki page if the port is done:
https://wiki.
gt;
> Thanks,
> Kiall
>
> On 17/07/15 12:32, Victor Stinner wrote:
> > Hi,
> >
> > We are close to having a voting py34 gate on all OpenStack libraries and
> > applications. I just made the py34 gate voting for the 5 following
> > projects:
> >
&
Hi,
We are close to having a voting py34 gate on all OpenStack libraries and
applications. I just made the py34 gate voting for the 5 following projects:
* keystone
* heat
* glance_store: Glance library (py34 is already voting in Glance)
* os-brick: Cinder library (py34 is already voting in Ci
Le 16/07/2015 22:28, Thomas Goirand a écrit :
IMO, we should, for the Liberty release, get rid of:
- suds & suds-jurko
suds was replaced with suds-jurko (in oslo.vmware, cinder, nova): I
kicked suds off of global requirements.
- memcached (in the favor of pymemcache)
As I wrote, I may for
Hi,
Le 16/07/2015 17:00, Davanum Srinivas a écrit :
I ended up here:
https://github.com/linsomniac/python-memcached/issues/54
https://github.com/linsomniac/python-memcached/pull/67
Oh, that's my pull request :-) Multiple peoples asked to merge my pull
request, and I pinged explicitly the main
Hi,
On 09/07/2015 16:29, Ian Cordasco wrote:
Thanks for your hard work Victor! I'll bring up a new release today in the
Glance meeting (currently running) and see if Nik and I can bug the
release managers for a new release today.
Any update on this release?
In the meeting report, I read:
"14:
Hi,
The latest release of os-brick is not compatible with Python 3.
Different patches were merged to fix Python 3 support. "tox -e py34" now
executes all tests and all tests pass on Python 3.4.
I need a release of os-brick to port Cinder to Python 3. A Python 3
issue in os-brick blocks my 4
On 13/07/2015 13:57, Jeremy Stanley wrote:
people on 2.6-only platforms who want to install and run
python-novaclient from PyPI can use the stable/juno version (though
I'll admit that finding which version works with 2.6 may be a tricky
proposition for a consumer who is unaware of this situation)
Le 10/07/2015 13:39, Jeremy Stanley a écrit :
On 2015-07-10 13:21:56 +0200 (+0200), Victor Stinner wrote:
I see "mock===1.0.1" in upper-constraints.txt, but the python27
check job of Swift was broken by the release of mock 1.1.
Can someone please explain me why Swift check job failed
On 10/07/2015 10:42, Robert Collins wrote:
Releasing this on a Friday sounds like bad timing, especially without
advance notice that we'd have to rush to fix the dozens of new issues it
would expose.
There would never be a good time to release such things. The whole
point of the constraints sys
Here is a fix for Swift:
https://review.openstack.org/200474
Victor
On 10/07/2015 09:45, Robert Collins wrote:
Good news everybody, mock 1.1.0 is now out. This backports all the
improvements over the last couple of years, making it fully
synchronised with cPython master. Yay.
Bad news. Lots of
Hi,
gate-glance-python34 is now voting!
Ian Cordasco and Erno Kuvaja approved my two last patches to port
glance_store to Python 3: thanks. "tox -e py34" now pass successfully,
cool! I proposed a "Make gate-glance_store-python34 voting, add gate"
patch to avoid Python 3 regressions in glance_
Hi,
On 07/07/2015 19:42, John Dickinson wrote:
For the dependencies (pyeclib), we'll get those as we can. The first priority
is getting the Swift code, which we control, ...
I used the hack suggested by Cyril Roelandt: patch pyeclib in tox. With
this hack, tox -e py34 now works even if pyecl
Le 07/07/2015 18:13, Clint Byrum a écrit :
Any time we have versions appearing in code or docs, I cringe, because
versions and releasing are separate from coding and documenting.
If I'm adding a parameter today in the latest commit after 1.0.0, I
really don't know if the next version released wil
Hi,
Oslo libraries become more and more stable, cool :-) Sometimes, we have
to modify APIs, to fix bugs, to deprecate functions, to add new function
parameters, etc. It would be cool to _document_ these changes. Sphinx
provides nice markups to document API changes:
http://sphinx-doc.org/m
Hi,
I have 9 pending patches to fix Python 3 issues in Swift, but they
didn't get much attention yet. Most of these patches replace a pattern
with a new pattern to add Python 3 support in addition to Python 2 support.
https://review.openstack.org/#/q/owner:%22Victor+Stinner%22+status:open+pro
Hi,
Unfortunately, it looks like each regressions introduced by releases of
Oslo libraries are still common :-( We already have tools to detect
regressions, but they are run manually. It would be nice to automate
these tests and run them more frequently (at least one per week, or even
daily?)
Le 30/06/2015 10:32, Victor Stinner a écrit :
I updated my patch "Update test_db_api for oslo.db 2.0" (1) ...
(1) https://review.openstack.org/#/c/196719/
I updated my patch again to also block oslo.versionedobjects 0.5.0 in
requirements. So we can have two patches to fix the
Hi,
Le 30/06/2015 05:49, Matt Riedemann a écrit :
Alternatively, oslo.versionedobjects 0.5.1 is cut after
https://review.openstack.org/#/c/196926/ is merged and then we just need
haypo's test_db_api fix for the oslo.db 2.0.0 change:
https://review.openstack.org/#/c/196719/
I updated my patch
Hi,
Le 29/06/2015 11:03, Thomas Goirand a écrit :
cliff-tablib is used for the unit tests of things like
python-neutronclient. The annoying bit is that cliff-tablib depends on
tablib, which itself is a huge mess. It has loads of 3rd party embedded
packages and most of them aren't Python 3.x comp
Hi,
The Python 3.4 gate (py34) of cinder, glance and nova just became
voting. You now have to write Python code compatible with Python 2.7 and
3.4.
If the py34 check job fails on your patch, you may try to rebase it to
get the new tox.ini and updated requirements.
You can find information
Hi,
Le 26/06/2015 09:17, 孙明达 a écrit :
I am a new contributor for openstack.
the following url is my code review for glance_store
https://review.openstack.org/#/c/193403/
Jenkins check failed on gate-glance_store-python34
Referring to the console info, I have never changed the code me
Hi,
We made great progress on porting Glance to Python 3. tox -e py34 now
pass with a subset of tests and there is a non-voting py34 check job. I
propose to make the py34 gate voting to avoid Python 3 regressions:
https://review.openstack.org/194048
"Make gate-glance-python34 voting"
When th
Hi,
Le 18/06/2015 15:44, Thomas Goirand a écrit :
As per the subject line, we already have Python 3.5 in Debian (AFAICT,
from Debian Experimental, in version beta 2). As a consequence, we're
already running (unit) tests using Python 3.5. Some have failures: I
could see issues in ceilometerclient
Hi,
Le 10/06/2015 02:15, Robert Collins a écrit :
python2.7 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
d.items(): pass'
10 loops, best of 3: 76.6 msec per loop
python2.7 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
d.iteritems(): pass'
100 loops, best of 3: 22.6
Hi,
Le 10/06/2015 22:17, Davanum Srinivas a écrit :
Oslo folks, everyone,
mox3 needs to be maintained since some of our projects use it and we
have it in our global requirements.
Here's the proposal from Doug - https://review.openstack.org/#/c/190330/
Why not only creating a project on Githu
Good news: your fix is already merged into oslo.messaging ;-)
oslo.messaging now uses directly mox3, on Python 2 and Python 3.
Victor
Le 10/06/2015 14:04, Victor Sergeyev a écrit :
Hi All,
this oslotest release break oslo.messaging gate - unittest fails
with ImportError, on import mox from si
1 - 100 of 197 matches
Mail list logo
