Re: [openstack-dev] [all] We're combining the lists!

On Sat, 10 Nov 2018 at 23:03, Thierry Carrez wrote: > > Robert Collins wrote: > > There don't seem to be any topics defined for -discuss yet, I hope > > there will be, as I'm certainly not in a position of enough bandwidth > > to handle everything *stack related. > >

Re: [openstack-dev] [all] We're combining the lists!

On Sat, 10 Nov 2018 at 07:15, Jeremy Stanley wrote: > > REMINDER: The openstack, openstack-dev, openstack-sigs and > openstack-operators mailing lists (to which this is being sent) will > be replaced by a new openstack-disc...@lists.openstack.org mailing > list. The new list is open for

Re: [openstack-dev] [all][requirements] a plan to stop syncing requirements into projects

On 26 March 2018 at 09:08, Doug Hellmann wrote: > Excerpts from Doug Hellmann's message of 2018-03-25 16:04:11 -0400: >> A few of the jobs failed because the dependencies were wrong. In a few >> cases I was able to figure out what was wrong, but I can use some help >> from

Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

On 20 February 2018 at 04:39, Andrey Kurilin wrote: > Can someone explain me the reason for including "tests" module into > packages? Namespacing the tests makes the test ids unique which is very helpful for aggregating test data as we do. Including that in the tar.gz

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

On 3 Feb. 2017 16:14, "Robert Collins" <robe...@robertcollins.net> wrote: This may help. http://jam-bazaar.blogspot.co.nz/2009/11/memory- debugging-with-meliae.html -rob Oh, and if i recall correctly run snake run supports both heapy an

Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

This may help. http://jam-bazaar.blogspot.co.nz/2009/11/memory-debugging-with-meliae.html -rob On 3 Feb. 2017 10:39, "Armando M." wrote: > > > On 2 February 2017 at 13:36, Ihar Hrachyshka wrote: > >> On Thu, Feb 2, 2017 at 7:44 AM, Matthew Treinish

Re: [openstack-dev] [all][infra][requirements] Odd cases in requirements?

On 10 Nov 2016 9:29 PM, "Tony Breeds" <t...@bakeyournoodle.com> wrote: > > On Thu, Nov 10, 2016 at 08:48:16PM +1300, Robert Collins wrote: > > > We generate multiline constraints whenever versions are different > > between python 2 and 3 for the same package

Re: [openstack-dev] [all][infra][requirements] Odd cases in requirements?

On 10 November 2016 at 11:00, Tony Breeds <t...@bakeyournoodle.com> wrote: > On Thu, Nov 10, 2016 at 06:17:44AM +1300, Robert Collins wrote: >> Sed doesn't exist on windows, whereas a python script can. Sed doesn't >> handle multiple line constraints. > > I don't t

Re: [openstack-dev] [all][infra][requirements] Odd cases in requirements?

Sed doesn't exist on windows, whereas a python script can. Sed doesn't handle multiple line constraints. Rob On 10 Nov 2016 12:00 AM, "Ihar Hrachyshka" wrote: > > > On 8 Nov 2016, at 04:07, Tony Breeds wrote: > > > > On Sat, Sep 03, 2016 at

Re: [openstack-dev] [requirements][all] What does the future look like?

I'm not in Barcelona, but am interested : please do try to capture some prose around the resulting design for us there-in-spirit folk. -Rob On 26 October 2016 at 01:50, Tony Breeds wrote: > Hi All, > I'd like to highlight a requirements session: > >

Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

On 31 August 2016 at 01:57, Clint Byrum wrote: > > > It's simple, these are the holy SQL schema commandments: > > Don't delete columns, ignore them. > Don't change columns, create new ones. > When you create a column, give it a default that makes sense. I'm sure you're aware of

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

On 12 August 2016 at 12:09, Clay Gerrard wrote: > > > On Fri, Aug 12, 2016 at 11:52 AM, Andreas Jaeger wrote: >> >> On 08/12/2016 08:37 PM, Clay Gerrard wrote: >> > >> > ... but ... it doesn't have a --install option? Do you know if that is >> > strictly

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

Fantastic news Andreas! -Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

On 11 Aug 2016 3:13 PM, "Ben Swartzlander" wrote: > > ... > > I still don't agree with this stance. Code doesn't just magically stop working. Code breaks when things change which aren't version controlled properly or when you have undeclared dependencies. Well this is why

Re: [openstack-dev] [all] Status of the OpenStack port to Python 3

On 27 June 2016 at 13:20, Jens Rosenboom wrote: > 2016-06-22 9:18 GMT+02:00 Victor Stinner : >> Hi, >> >> Current status: only 3 projects are not ported yet to Python 3: >> >> * nova (76% done) >> * trove (42%) >> * swift (0%) >> >>

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

Removing the pbr branch should be fine - it was an exceptional thing to have that branch in the first place - pbr is consumed by releases only, and due to its place in the dependency graph is very very very hard to pin or cap. -Rob On 25 June 2016 at 12:37, Tony Breeds

Re: [openstack-dev] [requirements][all] VOTE to expand the Requirements Team

Sure. +1 On 17 June 2016 at 02:44, Davanum Srinivas wrote: > Folks, > > At Austin the Release Management team reached a consensus to spin off > with some new volunteers to take care of the requirements process and > repository [1]. The following folks showed up and worked with

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

This might come across a little trolly/devils advocate, but I mulled on it for a few days, and I think I need to send it, so... fingers crossed you can extract some value from my questions. On 15 June 2016 at 01:57, Thierry Carrez wrote: > Hi everyone, > > I just proposed

Re: [openstack-dev] [tc][pbr][packaging][all] Definition of Data Files (config) in setup.cfg

On 12 June 2016 at 11:31, Thomas Goirand <z...@debian.org> wrote: > On 06/11/2016 05:02 AM, Robert Collins wrote: ... > Then keystone.conf ends up installed in /usr/etc/keystone when setup.py > install is used. With this configuration, it would be installed > correctly with

Re: [openstack-dev] [tc][pbr][packaging][all] Definition of Data Files (config) in setup.cfg

The underlying problem is as you say that distutils and setuptools and wheel are all different, and until there is a PEP addressing this *and* implemented in both wheel and setuptools, we won't get consistent behaviour. I'm pretty sure Daniel Hoth is interested in making this happen - there have

Re: [openstack-dev] [tc] supporting Go

On 19 May 2016 at 22:40, Dmitry Tantsur wrote: > >> You are correct that my position is subjective, but it is based on my >> experiences trying to operate and deploy OpenStack in addition to >> writing code. The draw of Go, in my experience, has been easily >> deploying a

Re: [openstack-dev] [fixtures] Re: [Neutron][Stable][Liberty][CLI] Gate broken

On 18 May 2016 at 19:55, Ihar Hrachyshka wrote: > >> On 18 May 2016, at 05:31, Darek Smigiel wrote: >> >> Hello Stable Maint Team, >> It seems that python-neutronclient gate for Liberty is broken[1][2] by >> update for keystoneclient. OpenStack

Re: [openstack-dev] [all][requirements] Refresher on how to use global requirements process

On 19 May 2016 at 01:40, Ihar Hrachyshka wrote: > Great write-up. Do you plan to capture it e.g. in project guide? It's already fully documented in the requirements repo README; if there is no link to that from the project-guide, we should add one, but I would not duplicate

Re: [openstack-dev] [requirements][all] First Requirements Team Meeting

On 17 May 2016 at 23:47, Davanum Srinivas wrote: > Team, > > Let's meet in #openstack-meeting-cp channel at 12:00 UTC on May 18th: > http://www.timeanddate.com/worldclock/meetingdetails.html?year=2016=5=18=12=0=0=43=240=195=166=83=281=141 > > We can decide if we need a better

Re: [openstack-dev] [tc] [all] [glance] Answers to some questions about Glance

On 18 May 2016 at 00:54, Brian Rosmaita wrote: >> Couple of examples: >> 1. switching from "is_public=true" to "visibility=public" > > > This was a major version change in the Images API. The 'is_public' boolean > is in the original Images v1 API, 'visibility' was

Re: [openstack-dev] [TripleO] [diskimage-builder] LVM in diskimage-builder

On 18 May 2016 at 07:32, Andre Florath wrote: > Hi All! > > AFAIK the diskimage-builder started as a testing tool, but it looks > that it evolves more and more into a general propose tool for creating > docker and VM disk images. We started as a fast, production, targeted

Re: [openstack-dev] [tc] supporting Go

On 13 May 2016 at 00:01, Thierry Carrez <thie...@openstack.org> wrote: > Robert Collins wrote: >> >> [...] >> So, given that that is the model - why is language part of it? Yes, >> there are minimum overheads to having a given language in CI [..

Re: [openstack-dev] [tc] supporting Go

I'm going to try arguing the pro case. The big tent has us bringing any *team* that want to work the way we do: in the open, collaboratively, in concert with other teams, into OpenStacks community. Why are we using implementation language as a gate here? I assert that most deployers don't

Re: [openstack-dev] [tc] supporting Go

d chatting via locks. Using an RPC model (similar to privsep) would probably be more flexible and easier, with at most a small speed cost. Worth trying a few things to get experience? -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguishe

Re: [openstack-dev] Wiki

onical-identity-provider -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ..

Re: [openstack-dev] [tc] supporting Go

Stack as a whole) are driving whatever specific problem you've got? I know that our current programming model is missing a lot of the easily-correct improvements that have been created in the last few decades (because our basic abstraction is the thread) - how much does that factor in, do you think?

Re: [openstack-dev] [tc] supporting Go

omething handling TCP will rapidly run into terrible scaling problems - quadratic overheads - with select. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __ OpenStack Devel

Re: [openstack-dev] [tc] supporting Go

re actually using the best facilities of our existing languages first! On the Designate side, PyPy got a 40% performance improvement over CPython for a benchmark of Twisted's DNS component 6 years ago - and Twisted and PyPy have both moved forward a great deal since then http://morepypy.b

Re: [openstack-dev] Team blogs

ing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud _

Re: [openstack-dev] [requirements] Bootstrapping new team for Requirements.

ease! > > Thanks, > Dims > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.opensta

Re: [openstack-dev] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

That won't get you running the new kernel; for that you need to change the image itself. -Rob __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [oslo] Backwards compatibility policy

-neutronclient etc etc: though I believe folks in such projects are generally cautious as well. The key thing here is that we already have to do backwards compat to move folk off of a poor API onto a new one: all this policy says is that the grace period needs to cross release boundaries. -Rob -- Robert

Re: [openstack-dev] backwards compatibility followup

e libraries thread :)). I wonder how many other folk are trying to attempt such a thing - anyone care to raise their metaphorical hand? -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __

[openstack-dev] backwards compatibility followup

out and used), we can do our garbage collection much more rapidly - even same-cycle. https://etherpad.openstack.org/p/newton-backwards-compat-libs -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged

Re: [openstack-dev] [nova] Distributed Database

one per DB for a few DBs...) - an 80% thing - so folk can actually assess how it look/feel at both a code and ops perspective. Then, if the result *has met* those essential things, we should actually have the ability to do a gap analysis and talk about how a project to move to such a thing would

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

ends on both and we want to be able to actually install Nova. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) U

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

r constraints in > another package on the system, the distro will just hold Nova back. And presumably all of OpenStack. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud _

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

few weeks would offset the cost of micromanaging every > constraint update. I also argued at the time that we should aim for entirely automated check-and-update. This has stalled on not figuring out how to run e.g. Neutron unit tests against requirements changes - our coverage is just too low at

Re: [openstack-dev] [release][requirements][packaging][summit] input needed on summit discussion about global requirements

if constraints are federated out to multiple trees. Never needing any two projects to agree on compatible versions in CI would allow us to change things without triggering a wedge... possibly. *detailed* thought needed here - because consider for instance the impact of a removed release on PyPI. -

Re: [openstack-dev] [all][elections] Results of the TC Election

t; your voice is heard. > > Thank you for another great round. > > Here's to Newton! > > Yours Tony. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscri

Re: [openstack-dev] [nova] [infra] The same SRIOV / NFV CI failures missed a regression, why?

nd PCI have been using - so whatever $behind-the-abstraction setup they are using, but community accessible and visible, unlike the current behind-corprorate-firewall setups. I'm not saying this is better or worse, but it is different to the tripleo approach of providing a Nova API endpo

[openstack-dev] [TC] TC Non-candidancy

Hi everyone - I'm not submitting my hat for the ring this cycle - I think its important we both share the work, and bring more folk up into the position of having-been-on-the-TC. I promise to still hold strong opinions weakly, and to discuss those in TC meetings :). -Rob -- Robert Collins

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

ublish to pypi. Libraries and clients however, are branching and being released from branches. Do we merge release tags to master for them? If so, thats probably perfect (though I haven't worked through it all in my head - public holiday here so only paying partial attention). -Rob -- Robert Collins

Re: [openstack-dev] [release][all][ptl][stable] requirements updates in stable/mitaka libraries

t; https://review.openstack.org/#/q/is:open+branch:stable/mitaka+topic:openstack/requirements > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/lis

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

e. So, I think we do need some aggressive means to bump master up past the versions reserved for a stable branch, at the stable branches creation. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologi

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

consult mod.__version__). Or you can alternatively query the standard (https://www.python.org/dev/peps/pep-0345/ ) metadata generated from python setup.py egg_info, if you prefer. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud _

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

On 25 March 2016 at 01:11, Alan Pevec <ape...@gmail.com> wrote: > 2016-03-24 2:21 GMT+01:00 Robert Collins <robe...@robertcollins.net>: >> Trunk will rapidly exceed mitaka's versions, leading to no confusion too. > > That's the case now, RC1 tags are reachable from bot

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

are packages distributed in the wild with version numbers that > have not been tagged. Thats ok, because thats an opt-in thing there - its not existing in the same namespace as the mitaka builds for rdo, is it? Trunk will rapidly exceed mitaka's versions, leading to no confusion too. -Rob -- Ro

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

egwork to make tags early on every time. But I don't think we've got supporting evidence that its more than you so far :). -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 10 Mar 2016 2:58 AM, "Radomir Dopieralski" wrote: > > On 03/09/2016 04:43 PM, Serg Melikyan wrote: >>> >>> This is exactly my first thought. The plugins *must* depend on Horizon, >>> and they have to use the same versions of XStatic packages anyways, > > >> so why

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

to go is sensible. As I blogged at the beginning of this cycle, I'm convinced that this is a useful opportunity for OpenStack as a whole, as well as for the individuals that attend - I'm very glad you've been pushing coordination of this fo

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 9 March 2016 at 14:23, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2016-03-09 13:57:45 +1300 (+1300), Robert Collins wrote: >> On 9 March 2016 at 13:07, Jeremy Stanley <fu...@yuggoth.org> wrote: >> > On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrot

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

user of xstatic when horizon updates'. :(. So -> IRC and/or/perhaps voice? -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not fo

Re: [openstack-dev] [all] audience for release notes

There is a fixture in pbr's test suite to create keys with out entropy use, should be easy to adapt for user by Reno's tests. On 1 Mar 2016 6:52 AM, "Thomas Goirand" wrote: > On 02/29/2016 10:31 PM, Doug Hellmann wrote: > >>> Give this a try and see if it works any better: > >>>

Re: [openstack-dev] How do I calculate the semantic version prior to a release?

ne of complexity. I see from http://www.rpm.org/ticket/56 that it only came in in RPM 4.10 - is RPM 4.10 available on all the RPM platforms we support? Including I guess old RHEL's and stuff? -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud ___

Re: [openstack-dev] How do I calculate the semantic version prior to a release?

don't see a similar command for getting the deb version. > > I threw together https://review.openstack.org/#/c/285250/ with some > additions to pbr's "info" command to expose these formats. I'll review in detail on gerrit, but we probably want an option to get a *released* versions of

Re: [openstack-dev] How do I calculate the semantic version prior to a release?

xes. No - its much more than that. See http://docs.openstack.org/developer/pbr/#version -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not

Re: [openstack-dev] How do I calculate the semantic version prior to a release?

it would be good too. > - the corresponding Debian version I don't think we expose that yet (but we should). > - the corresponding RPM version. As already mentioned, the rpm_version command exposes this. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguishe

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

https://review.openstack.org/#/c/280014/ > > What do you think? > > Thanks, > Dims > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > OpenStack Development Mailing List (not for usage questions) &

Re: [openstack-dev] [all][requirements] Why do we use pip install -U as our install_command

al projects do change things. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-

[openstack-dev] Mock and the stdlib

ncy, not conditional on any given version of Python. I'm sorry I didn't spot 268945 going through, or I would have -2'd it :(. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __

[openstack-dev] [oslo] Sachi King for oslo core

- which she has said she is and can. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-de

Re: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forward

their organisation that the focus is X, don't expect features to land - and that they are *expected* to help with the cycle. Without some framework, we're leaving those developers out in the cold trying to explain what-and-why-and-how all by themselves. -Rob -- Robert Coll

Re: [openstack-dev] [Neutron][[Infra] Gate failure

;> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > OpenStack Development Mailing List (not for usage questio

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

ersonally, I'm fine hacking on Twisted code - I quite like it (particularly good Twisted code :)) - and since folk seem ok with that aspect, great - thank you for raising the discussion here. I look forward to hearing how it goes for Ironic. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distin

Re: [openstack-dev] Further closing the holes that let gate breakage happen

opment Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

On 5 January 2016 at 11:59, Robert Collins <robe...@robertcollins.net> wrote: > This is odd indeed. pbr is not meant to have a dep on testrepository, > and you can see in > https://git.openstack.org/cgit/openstack-dev/pbr/tree/pbr/testr_command.py#n150 > that we only access it

Re: [openstack-dev] [oslo][nova][all] timeutils deprecation removals will break Nova

onto newer better ones, they create long term maintenance work for oslo: so we all need to work together to coordinate such things. https://review.openstack.org/#/c/226157/12 is part of this - it is an effort to bring consistency in expectations and process/patterns here. -Rob -- Robert Collin

Re: [openstack-dev] [gate] any project using olso.db test_migrations is currently blocked

n updated, there's a review setting -constraints as the expected pattern in the infra manual now. -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud __ OpenStack Deve

Re: [openstack-dev] [all] tox 2.3.0 broke tempest jobs

ystem images Assuming that thats correct, my suggestion would be that we either make tox pip installed during jobs (across the board), so that we can in fact control it with upper-constraints, or we work on functional tests of new images before they go-live -Rob -- Robert Collins <rbtcoll...@hp

Re: [openstack-dev] [oslo] stable/liberty branch needed for oslo-incubator

that code could have bugs and code require > backports to stable/liberty oslo-incubator for syncing to projects that use > it. I thought the thing to do was backport the application of the change from the projects master? -Rob -- Robert Collins <rbtcoll...@hpe.com> Distinguishe

[openstack-dev] [all] last-call backwards compat for libraries and clients spec

https://review.openstack.org/#/c/226157/ is very close to consensus now, at least as I read it. Please do weigh in this week, as I expect the cross project meeting next week to be the last discussion of it before it goes to the TC. Cheers, Rob -- Robert Collins <rbtcoll...@hpe.

Re: [openstack-dev] [oslo][glance][all] Removing deprecated functions from oslo_utils.timeutils

On 10 December 2015 at 18:19, Davanum Srinivas wrote: > So clearly the deprecation process is not working as no one looks at > the log messages and fix their own projects. Sigh! I think we need some way to ensure that a deprecation has been done: perhaps a job that we can run

Re: [openstack-dev] [oslo][glance][all] Removing deprecated functions from oslo_utils.timeutils

that projects using oslo > are failing to take up their share of things to be done. No, we should > not increase more responsibility on Oslo team. > > -- Dims > > On Thu, Dec 10, 2015 at 8:25 AM, Robert Collins > <robe...@robertcollins.net> wrote: > > On 10 December 2015 at 18

Re: [openstack-dev] [release] preparing your mitaka-1 milestone tag

nd git describe), the new tag doesn't exist, and so its like step 2 was skipped. So - to avoid confusing anyone, make sure you base the patch for step 3 on top of the revision being tagged in step 2. -- Robert Collins <rbtcoll...@hpe.com&

Re: [openstack-dev] [oslo][all] The lock files saga (and where we can go from here)

On 1 December 2015 at 08:37, Ben Nemec wrote: > On 11/30/2015 12:42 PM, Joshua Harlow wrote: >> Hi all, >> >> I just wanted to bring up an issue, possible solution and get feedback >> on it from folks because it seems to be an on-going problem that shows >> up not when an

Re: [openstack-dev] More and more circular build dependencies: what can we do to stop this?

- https://wiki.debian.org/DebianBootstrap#Circular_dependencies.2Fstaged_builds - covers the current state of the art, and should, AIUI, entirely address your needs: you do one build that is just a pure build with no tests-during-build-time, then when the build phase of everything is covered, a second stage

Re: [openstack-dev] [hyper-v] oslo.privsep vs Windows

> pip install mock > pip install nose > nosetests . i haven't seen any bug reports on testrepository vis-a-vis windows; please do file them, otherwise I'll presume it works. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cl

[openstack-dev] [pbr][oslo] volunteer needed to increase pbr test coverage of sphinx

in docs jobs across all of openstack, and its accruing project wide tech debt at an unpleasant rate :(. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __ OpenStack Develo

Re: [openstack-dev] [all] Thoughts on python-future?

ely if ever matters. Its that that makes me actually skeptical - the overheads of 2+3 single tree compat are really really low already, generally. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _

Re: [openstack-dev] [all] Thoughts on python-future?

evelopment Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Robert Collins <rbtc

Re: [openstack-dev] [release] process change for closing bugs when patches merge

Anyhow, thats a different discusion :) -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscrib

Re: [openstack-dev] [release] process change for closing bugs when patches merge

r the same fragility and need the same robustness if we're trying to guarantee that the comment is added. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __ OpenStack Develo

Re: [openstack-dev] [oslo] Should we make qpid/proton optional dependencies? (please say yes)

On 23 November 2015 at 22:33, Victor Stinner <vstin...@redhat.com> wrote: > 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.o

Re: [openstack-dev] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

he moment, since they change the packages that one needs to not use - but putting stuff in a user-install and not touching the system packages is still superior and doesn't require any purging etc. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguish

Re: [openstack-dev] [all] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-d

Re: [openstack-dev] [trove] trove unit tests failing on stable/kilo

ents.txt#L17 > > And that's terriblewhy are we doing that? I know you know this, but yeah - don't do that :). FWIW constraints *will* override that but liberty and above. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __

Re: [openstack-dev] [oslo][all] Oslo libraries dropping python 2.6 compatability

Yes, major version bump. As long as we don't have to change any consumers, we have no backwards compatibility concerns because we deprecated 2.6 in Juno. However i suspect we will have to change consumers specifically we still had 2.6 jobs in liberty On 17 Nov 2015 3:23 AM, "Davanum Srinivas"

Re: [openstack-dev] [oslo][testing-cabal] Help needed getting oslo.versionedobjects to install in tox venv

On 17 November 2015 at 16:25, Jay Pipes <jaypi...@gmail.com> wrote: > On 11/15/2015 08:10 PM, Robert Collins wrote: ... > > Thanks, Robert, but unfortunately that didn't work. I still get the same > problem: > > Downloading/unpacking .[fixtures] > Could not find

Re: [openstack-dev] [stable][neutron] upper constraints for stable/liberty

to advocate widespread adoption once the neutron master ones are voting > Does the plan make sense? Totally :) As non-Neutron-contributors we've just been conservative in our recommendations; if Neutron wants to move a little faster by taking on a little risk, thats *totally cool* IMO. -Rob --

Re: [openstack-dev] [oslo][testing-cabal] Help needed getting oslo.versionedobjects to install in tox venv

t remove python-pip python-virtualenv; install pip using get-pip.py; sudo -H pip install virtualenv More info here: https://rbtcollins.wordpress.com/2015/07/12/bootstrapping-developer-environments-for-openstack/ -Rob -- Robert Collin

Re: [openstack-dev] [release][stackalytics] possibly breaking bug closing statistics?

"date_fix_released": "2015-08-03T08:37:49.270140+00:00", > > Not sure if it's documented behavior or not, so the patch to Stackalytics > would probably > be preferred. Released implies committed: bei

Re: [openstack-dev] [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

l in production running Diablo... -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ..

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

ts all those priorities, and redis does not. Its possible that etcd and or consul do: though they are much newer and so perhaps fail on the maturity scale. I'm certain redis does not - at least, not unless the previously reported defects have been fixed in the last 2 years. -Rob -- Robert C

Re: [openstack-dev] [all] Outcome of distributed lock manager discussion @ the summit

t that request rate / latency could be a potential issue as clouds scale (e.g. need care and feeding). -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __ OpenStack Deve

  1   2   3   4   5   6   7   8   9   10   >