pread 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
70140+00:00",
>
> Not sure if it's documented behavior or not, so the patch to Stackalytics
> would probably
> be preferred.
Released implies committed: being defensive here won't hurt but is IMO
entirely unneeded.
-Rob
--
Robert Collins
Distinguished Technologist
HP C
zk meets 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
iablo...
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
ry- large cloud to stress the cluster size of any decent DLM, but
that request rate / latency could be a potential issue as clouds scale
(e.g. need care and feeding).
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
o reduce
> amount of GET requests and avoid DDoS of OpenStack..
>
> In any case it doesn't seem like hard task to collect the numbers.
Please do!.
But for clarity - in case the sub-thread wasn't clear - I was talking
about the numbers for a websocket based push thing, n
ld that zookeeper is already used in CI jobs
for ceilometer (was this wrong?) and thats why we figured it made a
sane default for devstack.
We can always change the default later.
What is important is that folk step up and write the consul and etcd
drivers for the non-Java-happy
down-the-track way to
address it.
And the reason I'm doing that is that Clark has said that we have lots
and lots of trouble updating images, so I'm expecting the corner case
to be fairly common :/.
-Rob
--
Robert C
nd the stacks we have - apache, eventlet - have been around long
enough to adjust to the rather different scaling pattern.
So - lets not panic, get a proof of concept up somewhere and then run
an actual baseline test. If thats shockingly bad *then* lets panic.
-Rob
--
Robert Co
have a network mirror with prebuilt wheels with some care,
but thats a bit more work. The upside is we could be refreshing it
hourly or so without a multi-GB upload.
-Rob
--
Robert Collins
Distinguished Technologist
HP C
copy of upper-constraints.txt to
release-constraints.txt and then test both cases in the gate.
We can always pull up an older version of upper-constraints.txt in
liberty's history, so I see no particular reason not to approve manual
point release changes to upper-constraints.txt in liberty.
-Rob
ver is a test driver - in the
module name at minimum
All hail our new abstraction overlords.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage qu
repository, testscenarios, testresources, unittest2, traceback2
and linecache2 - generally everything :)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usa
> OpenStack Development 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
Distinguished Technologist
HP Converged Cloud
_
ld be ok
since it wouldn't cascade.
But yeah, informational would be fine - we can socialise 'treat it as
voting' amongst the committers easily enough.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
r - just having the confidence that we haven't accidentally
broken anything until well past the point that the last release of a
higher level library is no longer accepting bug reports - that would
be the goal.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
On 16 October 2015 at 12:09, Matthew Thode wrote:
> On 10/15/2015 06:00 PM, Robert Collins wrote:
> Thanks for the replies, I think I have a way forward (using upper-reqs
> as a cap). I might need to make a tool that munges the (test-)reqs.txt
> to generate one as an easier refere
thats the debate
we're having about backwards compat in clients and libraries.
{Note that we've never systematically capped third party libraries and
so they are always a potential surprise too - but its again the
balance between presume-bad and presume-good behaviour from the
upstre
On 16 October 2015 at 11:21, Matthew Thode wrote:
> On 10/15/2015 05:12 PM, Robert Collins wrote:
>> On 16 October 2015 at 08:10, Matthew Thode wrote:
>>> On 10/15/2015 02:04 PM, Robert Collins wrote:
>> ...
>>>>> Where are my caps?
>>>>
>&
On 16 October 2015 at 08:10, Matthew Thode wrote:
> On 10/15/2015 02:04 PM, Robert Collins wrote:
...
>>> Where are my caps?
>>
>> The known good versions of dependencies for liberty are
>> http://git.openstack.org/cgit/openstack/requirements/tree/upper-co
00
that it was slated for, where its squarely on topic :)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
u should be able to trivially pull those versions out and into your
liberty set of packages.
Theres another iteration on this in discussion now, which has to do
with backwards compat *and testing of cap changes*, we'll be in the
backwards compat fishbowl session in Tokyo if you're intere
7;d see to fix this situation, would be a PEP. This will
> probably take a decade to have everyone switching to a new correct way
> to write a long & short description...
Perhaps Debian (1 thing) should change, rather than trying to change
all the upstreams packaged in it
___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-b
rives this is a combination - e.g. coming in part from
defects in pip, and the existence of things that can't be installed in
virtualenvs.
Obviously a trivial workaround is to always use virtualenvs and not
system-site-packages.
To sum up the thread, it sounds to me like a viable way-forward is:
at the dogtag-pki packages in Debian are up to
date - perhaps more discussion w/ops is needed?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usa
new thing against our known needs at each
step, that might reduce the risk.
But the biggest risk I see is the one Sean already articulated: we
have only a vague idea about how folk are /actually/ using what we
built, and thus its very hard to predict 'changing X will break
someone&
quests 2.7.0 or higher
> are being used. In other systems, this problem still exists and cannot be
> fixed by requests directly.
Well, if we get to a future where it is in-principle fixed, I'll be happy.
-Rob
--
Robert Collins
Distinguished Technologist
HP Conve
stainable way forward, that would be great: please don't feel
cut out, I'm just not expecting anything.
If there are other approaches, great - please throw them up here.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
-config...
at which point we can point at that as the template and encourage
wider adoption. Constraints jobs would have allowed back-pressure on
picking up the new release (e.g. if we had neutron unit test jobs
voting on requirements changes).
-Rob
so we can at least press ahead with picking a name for
>> N asap which is permitted by current rules.
>
> Agreed. I believe that Monty and Jim signed up for shepherding this
> after the last naming rules change. I've added it to the TC agenda for
> next week to kick
org/#/c/226157/ at the moment, which while
its aimed at clients and libraries is at least in the same discussion
space
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mai
ches of oslo.utils: something I hope we can stop doing in M
(I have a draft spec up about this...)
Libraries have security bugs too, and packagers/distros need to update
them as well as the API servers: this is one of the reasons we have
backpressure on libraries being
and I'd like love to fix that. In fact I'd
like to make it as nice as it is in py.test - I have a plan, and I'd
be delighted to turn it into a spec that someone can follow if anyone
would like to fix this - I think it would be quite high leverage a
thing. OTOH, because its an e
y the gate isn't wedged, its just broken... for a lot of folk :))
You will need to manually submit the same pillow cap to Nova (With a
comment before it). Like this:
https://review.openstack.org/#/c/230245/ (Thanks Tony).
Once we're all sorted out we can
thubusercontent.com/openstack/horizon/master/doc/source/topics/settings.rst
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/
> OpenStack Development 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
Distinguished Technologist
HP Converged Cloud
_
ing with +1/-1 as usual.
>
> Doug
>
> __
> OpenStack Development 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
leno())
fdatasync would be better - we don't care about the metadata.
> between the existing f.write() and f.close(), and then add something like:
>
> f = open(volumes_dir, 'w+')
> os.fsync(f.file
On 23 September 2015 at 02:03, Thierry Carrez wrote:
> Robert Collins wrote:
>> [...]
>> So, one answer we can use is "The version impact of a requirements
>> change is never less than the largest version change in the change."
>> That is:
>> nothi
On 23 September 2015 at 02:48, Jeremy Stanley wrote:
> On 2015-09-22 15:16:26 +1200 (+1200), Robert Collins wrote:
> [...]
>> 'Is this requirements change an API break' or 'is this requirements
>> change feature work' or 'is this requirements change
t that
> analysis I would rather continue over-simplifying the analysis of
> requirements updates.
So how about we [from a releases perspective] just don't comment on
requirements syncs - let projects make their own asses
It's the same number of patches.
On 23 Sep 2015 4:42 am, "Matt Riedemann" wrote:
>
>
> On 9/22/2015 4:59 AM, Alan Pevec wrote:
>
>> 2015-09-21 16:12 GMT+02:00 Monty Taylor :
>>
>>> We're running a script right now to submit a change to every project with
>>> this change. The topic will be coverag
to pick minor versions always as the
evolving process in the releases team does, but because requirements
changes *can* be API breaks to users of components, I think that that
is too conservative.
A fourth one would be to pick patch level for eve
this a
non-silent failure, though due to the evolution of the IO layer across
different Python versions its a little tricky :/.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Ma
the safe ones at once and zero in on the
incompatibility - and get it addressed.
To repeat: this is effectively a release blocker IMO, and the release
is happening - well, $now.
-Rob
--
Robert Collins
Distinguished Techno
nt that those things are possible, but currently its
future work.
So - I think the pragmatic thing here is to:
- review the CI for A and B here to see if we can prevent the
incompatibilities occuring at all in future transitions like this
[expand-contract is a much safer pattern and should be usab
https://review.openstack.org/#/c/221157/ is the updated review to
bring it all together. I'm worried that the incompatibility is going
to impact distributors and/or may even be from one of our own recent
library releases.
--
Robert Collins
Distinguished Technologist
HP Conve
ut I will say that I think that the goals you've
identified are well within our [all OpenStack contributors] power to
address during the next cycle, and I'm going to help facilitate that
however I can.
-Rob
--
Robert Col
y.
> [1] Bonkers is a recognized technical term right?
That seems like it will work [resists urge to kibbitz on the capping thing].
Perhaps you'd want to add the caps first across all trees, then do the
minimum raising in master/liberty. Seems like J mig
On 11 September 2015 at 07:48, Nikhil Komawar wrote:
> Hi all,
>
...
> 3. python-glanceclient upgrades need to be done in staged manner and by
> cross-checking the rel-notes or preferably commit messages if your
> deployment is fragile to upgrades. A CI/CD pipeline shouldn't need such
> back compa
On 11 September 2015 at 07:23, Robert Collins wrote:
> Note that master is pinned:
>
> commit aca1a74909d7a2841cd9805b7f57c867a1f74b73
> Author: Tushar Gohad
> Date: Tue Aug 18 07:55:18 2015 +
>
> Restrict PyECLib version to 1.0.7
>
> v1.0.9 rev of PyECL
oment
Change-Id: I52180355b95679cbcddd497bbdd9be8e7167a3c7
But it appears a matching change was not done to j/k - and the pin
hasn't been removed from master.
-Rob
--
Robert Collins
Distinguished Techno
OTOH with something like os-brick, brand new, all
versions may well be ok.
Cheers,
Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage questions)
Unsubscri
t code hang around in-tree for much longer
So the backwards compatibility aspect of this discussion is really
just the tip of the iceberg.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
On 10 September 2015 at 07:33, Sean Dague wrote:
> On 09/09/2015 02:55 PM, Robert Collins wrote:
>> On 10 September 2015 at 06:45, Matt Riedemann
>> wrote:
>>>
>>
>>> The problem with the static file paths in rootwrap.conf is that we don't
>>
twrap files
are actually secure). And its massively lower latency and better
performing.
https://review.openstack.org/#/c/204073/
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenS
On 2 September 2015 at 11:53, Angus Salkeld wrote:
> 1. limit the number of resource actions in parallel (maybe base on the
> number of cores)
I'm having trouble mapping that back to 'and heat-engine is running on
3 separate servers'.
-Rob
--
Robert Collins
Distingu
t weeks cross-project meeting?
Maybe.
Kilo is going to be an issue for another cycle, and then after that
this should be SO MUCH BETTER.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
Ope
It's not needed for 2.6 either - unit test 2 includes a more up to date
discover implementation.
On 28 Aug 2015 5:21 am, "Matt Riedemann" wrote:
>
>
> On 8/27/2015 6:26 AM, Chandan kumar wrote:
>
>> Hello,
>>
>> I am packaging 'discover' module <
>> https://bugzilla.redhat.com/show_bug.cgi?id=125
I use the old
> requirements.txt to install dependencies, there must be many packages are
> installed as upstream versions and some of them breaks. An ugly way is to
> copy pip list from old Juno environment and install those properly. I hope
> there are better ways to do this work. An
On 27 August 2015 at 01:31, Thomas Goirand wrote:
> On 08/25/2015 11:20 PM, Robert Collins wrote:
>>> So I can't upload PBR 1.3.0 to Sid. This has been dealt with
>>> because I am the maintainer of PBR, but really, it shouldn't have
>>> happen. How com
test-requirements.txt -r thisnewfile ...' or it
will bail, which means 'pip install -r test-requirements.txt -r
thisnewfile' and let requirements.txt come in via the egg info
reflection in pbr; which means url deps (deprecated anyway) won't
work.
- but devs can still be confuse
- but a negative
lookahead regex is the right way to disable known buggy tests, yes.
> Please comment if you think that's the wrong way to go. Also, has some
> of these been repaired in the stable/kilo branch?
Few to none, but I think they'd be valid to backport.
-Rob
--
Ro
email, but since you've raised the points
here I feel compelled to proffer a different explanation of the issues
you're reporting.
On 26 August 2015 at 01:42, Thomas Goirand wrote:
> Hi,
>
> This is a special message for Robert Collins, as I believe he's the one
> respo
sly, if you're *actually* using mock and there is a problem, we
can and should fix it :)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usa
On 22 August 2015 at 11:50, Dave Walker wrote:
> On 22 August 2015 at 00:04, Matthew Thode wrote:
>> On 08/21/2015 05:59 PM, Robert Collins wrote:
>>> On 22 August 2015 at 10:57, Matthew Thode wrote:
>>>> Packaging for us is fairly easy, but it is annoying to
reinventing *everything* ?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
y on the assumption that
you'll upgrade all the things as fast as possible to ensure security].
Distributors probably care about vendoring, but IMO we should ignore
that. Projects that vendor do so with consideration for stability and
user experience - and even so is pretty rare in the Python s
>
>
> On Thu, Aug 20, 2015 at 12:53 PM Andreas Jaeger wrote:
>>
>> On 08/20/2015 09:32 PM, Robert Collins wrote:
>> > It was just removed from global requirements, because it was not used.
>> > That's clearly wrong. So let's refer that and add it
It was just removed from global requirements, because it was not used.
That's clearly wrong. So let's refer that and add it back.
On 21 Aug 2015 6:27 am, "Andreas Jaeger" wrote:
> The requirements proposal job fails syncing to congress with this error:
> "'PuLP' is not in global-requirements.txt"
On 21 Aug 2015 6:45 am, "Jim Rollenhagen" <
>
> +1, there are tons of dragons here. Now that we're to the point where
> our state machine is well-defined with a single entrypoint, I think
I'm clearly confused. When was 1.6 deleted?
Rob
_
lready packaged
- unusual licences
E.g. things which are easy, either because they can just use existing
dependencies, or they're pure python, we shouldn't worry about.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
the specific issue should be to not install
the python-cffi package, but I couldn't trivially figure out what was
triggering the install. Not installing it would make devstack on
Fedora faster (since we're still installing the thing from PyPI as
well..)
-Rob
--
Robert Collins
Distinguis
On 19 August 2015 at 21:19, Thierry Carrez wrote:
> Robert Collins wrote:
>> [...]
>> Proposed data structure:
>> - create a top level directory in each repo called release-notes
>> - within that create a subdirectory called changes.
>> - within the rele
, so other tooling can look for a constant value.
If we want to put release notes in sdists, we can have pbr do this,
otherwise it could just be built entirely separately.
I recommend we start with it entirely separate: part of the
release-management
n openstack/requirements that checks
devstack-on-fedora, fedora developers will be exposed to this sort of
thing from time to time :/.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Develop
VER.
4) Don't default the client to the veresions between 1.10 and NEWVER
versions at any point.
That seems like a very small price to pay on our side, and the
benefits for users are that they can opt into the new functionality
when they are r
eview.openstack.org/#/c/213606/.
Of course, if there is something the current mechanism doesn't do, I
and many others will be delighted to discuss how to improve it or
alter the setup, but what you propose seems to be strictly less good
and offer no benefits.
-Rob
--
Robert Collins
Dis
evelopers.
To put this in context, we have nearly 400 (including transitive)
dependencies including all the ones we create. We're hurting thousands
of people to help hundreds of projects /urgently/. I don't think that
makes sense.
Rather, lets help those projects gracefully: keep ge
worth the benefit of making incompatible upstream
releases be disruptive. Signal is important, stress is harmful: we
want signal without stress IMO.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
On 14 August 2015 at 11:05, Sean M. Collins wrote:
> On August 13, 2015 3:45:03 AM EDT, Robert Collins
> wrote:
>>
>> tl;dr - developers running devstack probably want to be using
>> USE_CONSTRAINTS=True, otherwise there may be a few rough hours today.
>> [http:/
o its possible we'll be dealing with a
dual-defect problem.
That said, again, constraints correctly insulated devstack from the
1.6.2 release - we detected it when the update proposal failed, rather
than in the gate queue, so \o/.
AFAICT the os-client-config thing won't affect any unit te
o releases; submit a proposed
release to openstack/releases. I need to pop out shortly but will look
in in my evening to see about getting the release tagged. If Dims or
Doug are around now they can do it too, obviously :)
-Rob
--
ich is a layer on unittest).
One note, don't import 'unittest' - always 'unittest2'.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not f
e entirely appropriate to bump the lower bound of
neutronclient in kilo: running with the version with juno caps *isn't
supported* full stop, across the board. Its a bug that we have a bad
lower bound there.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
om
> for patch releases on stable branches.
Right: any non-bugfix change should be a minor version bump. Most
(perhaps all?) dependency changes should be a minor bump. Some may
even qualify as major bumps.
-Rob
--
Robert Collins
Distinguished Technologist
H
Pip is listed there because we used to use pip from within pbr. We could
raise the pip version in global requirements safely I think.
On 8 Aug 2015 09:58, "Christian Berendt" wrote:
> On 08/07/2015 10:52 PM, Robert Collins wrote:
>
>> I don't know why Nova has a r
I don't know why Nova has a requirement expressed on pip, since
requirements.txt is evaluated by pip its too late. Does Nova actually
consume pip itself?
On 8 Aug 2015 8:31 am, "Christian Berendt" wrote:
> According to requirements.txt we require pip>=6.0. Trying to install the
> requirements for
master too.
> And this avoids inconsistency between master and stable beyond that
> required to rebase.
>
> Explanations of the many ways I'm wrong are always appreciated.
I think you're right on.
Something with the same process as ChangeLog generation today - read
from git, pr
uild it
> to submit a proposal to the releases repo at the same time, we would
> get the history tracking, too.
I think tagging is basically the only sensible route.
Untagged commits require some oracle to determine 'is this the stable
branch *itself* or not.
[Because local developer b
On 30 July 2015 at 05:27, Robert Collins wrote:
> 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.
&g
a few others, are pushing on:
- Aligning our designs with the ecosystem for less waste and
confusion all around.
- Doing the work we had previously done as layered workarounds as
root level patches to the various tools
While still rolling out the new thing
glance_store[swift] glance_store[vmware]
>
> I'll have to test this a bit. It may make more sense to simply have these
> be Glance dependencies since we're the only consumer of glance_store (for
> now).
If pip doesn'
hat happens if you want to enable multiple
>> backends? Can you do something like "pip install glance[swift, vmware]", or
>> would you need to run a separate pip command to install each?
>
> I think you would say:
>
> pip install glance[swift] glance[vmware]
That
On 30 July 2015 at 05:45, Sean Dague wrote:
> On 07/29/2015 01:21 PM, Robert Collins wrote:
>> However - see above - I think the impact of the release is being
>> overstated. If I have that wrong, please help me understand whats
>> happened here.
>
> I thought Matt sai
So really - I still don't buy 'exploding'. Two patches have themselves
depended-on changes in Kilo, and a third patch is a child of one of
those. Thats not a huge developer productivity sink to deal with.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
s ok
IMO. As long as we don't set upper bounds, we won't deadlock ourselves
like we did in the past.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing Li
rom 'error' to 'decide it knows
better'. It was arbitrary but conservative.
However - see above - I think the impact of the release is being
overstated. If I have that wrong, please help me understand whats
happened here.
-Rob
--
Robert Col
w, is that I'm travelling in 24 hours,
and releasing it closer to then would be bad, and the Python 3.5
release is happening, and it needs to sync reasonably closely with
that. Rock and hard place.
-Rob
--
Robert Collins
Distinguished Technologist
HP Conve
101 - 200 of 1124 matches
Mail list logo
