, but are something worth
tracking as you explore and think.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
various repos and think wow
that's an awful lot of changed code.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
.
This idea is best, but if a new name is required, tempit is good because it
is a) short b) might subconsciously remind people that testing ought to
be fast(-ish).
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
be applied to multiple strategic goals.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
the ceilometer API has
samples that span the upgrade.
Thoughts?
Thanks.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
On Mon, 18 Aug 2014, Chris Dent wrote:
The reason for doing this? I want to be able to confirm that some
sample data retrieved in a query against the ceilometer API has
samples that span the upgrade.
The associated change is here:
https://review.openstack.org/#/c/102354
--
Chris Dent tw
because as agents leave and join the group, where
samples are published from can change.
* How should it be named? The never-ending problem.
Thoughts?
[1] https://review.openstack.org/#/c/113549/
[2] https://review.openstack.org/#/c/115237/
--
Chris Dent tw:@anticdent freenode:cdent
https
also just the
simple matter that it is good data hygiene to know where stuff came
from?
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
flexible
testing.
I appreciate that searching through endless log files is a common
task in OpenStack but that doesn't make it the best way.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
this is
supposed to work isn't it?
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
functional tests:
* to reach places unit tests won't go
* to not have the noise of all that mock and OO mess
* to have some faith in the end to end
The sorts of things that require provisioning of temporary datastores,
interception of wsgi apps, in process message queues...
--
Chris Dent tw:@anticdent
documentors,
etc.).
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
one developer not on the core team handle a graduation for us.
+many more for the relatively simple act of just writing stuff down
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack
resolution.
* A cup of tea or other beverage of our choice and some sympathy
and commiseration. A bit of I too have suffered at the hands of
grenade. Then we can all be friends.
From my side I can provide a promise to follow through on
improvements we discover.
--
Chris Dent tw:@anticdent
are satisfied with robustness and
provide a contract between two endpoints. The other is to allow a
fecund notification environment that allows and enables many
participants.
Is that a good summary? What did I leave out or get wrong?
--
Chris Dent tw:@anticdent freenode:cdent
https
comes
from a general interest in now events and notifications are handled
throughout OpenStack.
Thanks.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
on it with me? I think it could wind up being a
pretty useful tool for folks outside of OpenStack too if we get it right.
Given availability (currently an unknown) I'd like to help with this.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
to think less about the projects and
technologies that are involved and more about the actions and results
that our efforts hope to allow and enable.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/044748.html
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com
On Sun, 7 Sep 2014, Monty Taylor wrote:
1. Caring about end user experience at all
2. Less features, more win
3. Deleting things
Yes. I'll give away all of my list for any one of these.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
of What is
OpenStack in the business of? and How do we stay sane while being in
that business?
Every long thread over the last couple of months has trended towards
those questions. It's getting pretty tiresome. We'd all be a lot
more focused if we knew the answer.
--
Chris Dent tw:@anticdent
in some way so we can also
constrain the consumer code.
Or maybe we should just use RDF and produce a super upper ontology
and consume all the world's knowledge as events? That's been super
successful in other contexts...
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com
On Fri, 12 Sep 2014, Julien Danjou wrote:
I guess the problem is more likely that testrepository load the tests
From the source directory whereas maybe we could make it load them from
what's installed into the venv?
This rather ruins TDD doesn't it?
--
Chris Dent tw:@anticdent freenode:cdent
else's problem.
--
Chris Dent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
the recommended path to make this happen?
Thanks.
[1] https://github.com/openstack/tempest/blob/master/tempest/cmd/javelin.py
[2] Definition of sane to be determined.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev
check run is happening before or after the upgrade stage?
Thanks for any help and input. I'm on IRC as cdent if you want to find me
there rather than respond here.
[1] https://review.openstack.org/#/c/102354/
[2] https://review.openstack.org/#/c/100105/
--
Chris Dent tw:@anticdent freenode:cdent
pause on the ceilometer stuff for a while. Thanks for the
quick response. I just wanted to make sure I wasn't crazy. I guess
not, at least not because of this stuff.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
. That is a BadThing™. I'm sure there are plenty of reasons for
why it has turned out that way, but if there is an opportunity for
change...?
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent___
OpenStack-dev mailing list
OpenStack-dev
virtualenv.
My next hope is to get rid of unittest and just do the plain asserts
that py.test makes so nice and lovely.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev
sweet!
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
those notifications are emitted. In those cases where pipeline
transformation needs to be done ( multiple value gathering) the pipeline
can consume certain notifications and then emit more as the result of
the transformation.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks
to make it possible:
http://paste.openstack.org/show/86071/
However on that however, if there's some chance that a large change could
happen, it might be better to wait, I don't know.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
limited one, how's it sound? Does it need an
implementation in order to warrant further discussion? Or would it
be better to toss it around a bit more? It makes no sense to me to
formalize something that has no potential legs.
Thanks for sticking through this.
--
Chris Dent tw:@anticdent
and I'm happy to do the leg
work to make it so, but I need a bit of guidance on where to push.
Thanks.
[1] http://lists.openstack.org/pipermail/openstack-dev/2014-July/039078.html
[2] The TC did some gap analysis and one of the areas that needs work
is in resource survivability.
--
Chris Dent tw
://review.openstack.org/#/c/97317/ - local testing gets us to an
unrelated ceilometer bug. However landing the 2 tempest patches first
should be done.
If you'd like me to look into that ceilometer bug, please let me
know what it is.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
events
that should have a very similar structure. If that structure is well
known and well accepted we will likely find that many existing
events can be bent to fit that structure for the sake of less code
and more reuse. As part of this process I'll try to figure out if this
is true .
--
Chris
opportunities?
[1] There's vernacular here that I'd prefer to use but this is a
family mailing list.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
'something failed'.
So, my question: Is this something we who dig around in the ceilometer
code ought to care about and make an effort to clean up? If so, I'm
happy to get started.
Thanks.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
:
LOG.exception('crisis!')
This makes it easier to distinguish between the noise and the nasty,
which I've found to be quite challenging thus far.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent___
OpenStack-dev mailing list
context of the The Entire
Project™).
I'll pay a bit closer attention to the specific relationship
between the ceilometer exceptions (on the loops) and the logs and
when I find something that particularly annoys me, I'll submit a
patch for review and we'll see how it goes.
--
Chris Dent tw:@anticdent
There's a review in progress for a generic event format for
PaaS-services which is a move with the right spirit: allow various
services to join the the notification party without needing special
handlers.
See: https://review.openstack.org/#/c/101967/
--
Chris Dent tw:@anticdent freenode:cdent
version (0.7.0)?
If there are issues please report them as bugs on github, they'll
get fixed:
https://github.com/cdent/python3-wsgi-intercept/issues
If there's a better way to do the optional-ness of mechanize
(without changing everything else), then please suggest something.
--
Chris Dent tw
(UTC) I can probably get the new
version out tomorrow too.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
on which way is the best way forward,
I'd prefer not to make the decision solo.
Let me know whenever you have a new release, without mechanize as new
dependency, or with it being optional.
It will be soon (a day or so).
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
On Tue, 29 Jul 2014, Chris Dent wrote:
Let me know whenever you have a new release, without mechanize as new
dependency, or with it being optional.
It will be soon (a day or so).
https://pypi.python.org/pypi/wsgi_intercept is now at 0.8.0
All traces of mechanize removed. Have at. Enjoy
/swift_middleware.py
[2] https://review.openstack.org/#/c/110302/
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman
the command line or in tox.ini.
Even if you don't know a way, I'd like to hear from other people who
would like it to be possible. It's one of several testing habits I
have from previous worlds that I'm missing and doing a bit of
commiseration would be a nice load off.
Thanks.
--
Chris Dent tw
Will link to this thread from the bugs for visibility.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo
:
https://wiki.openstack.org/wiki/Testr#FAQ
and included it in there. With luck other people will add stuff.
Now to see about speed.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
/openstack-dev/2014-July/thread.html#41057
[2]
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041188.html
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041252.html
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
to stop.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
not. There's tyranny of choice all over OpenStack. Is
that good for real people or just large players and our corporate
hosts?
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev
example, since it has _no_ arrows.
[3] their own, that's hateful, let's have less of that.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
something worth tracking? I would say yes.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
a new name on the room and don't change the people or
the room.
We need to do more this time around than change some names.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev
/metering/eventing (choose your term
of art).
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Mon, 25 Aug 2014, Joe Gordon wrote:
On Mon, Aug 4, 2014 at 3:29 AM, Chris Dent chd...@redhat.com wrote:
For constraints: Will tempest be available as a stable library? Is using
tempest (or other same library across all projects) a good or bad thing?
Seems there's some disagreement on both
.
There are solid arguments against each of these problems individually
but as a set I find them saying services should make more
notifications pretty loud and clear and obviously to make that work
we need tidy notifications with good clean semantics.
--
Chris Dent tw:@anticdent freenode:cdent
https
On Tue, 14 Oct 2014, Angus Lees wrote:
2. I think we should separate out run the server from do once-off setup.
Yes! Otherwise it feels like the entire point of using containers
and dockerfiles is rather lost.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
that the 1.3 release of Docker (any day now) will sport a
Yesterday:
http://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
that needs it
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
such things, especially
when it's just names in data fields. Not always possible, or even a
good idea, but sometimes its a win.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev
).
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
think we need to make a better list of the
use cases which the samples need to satisfy and use that to drive a
naming scheme.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev
On Mon, 20 Oct 2014, Jim Mankovich wrote:
On 10/20/2014 6:53 AM, Chris Dent wrote:
On Fri, 17 Oct 2014, Jim Mankovich wrote:
See answers inline. I don't have any concrete answers as to how to deal
with some of questions you brought up, but I do have some more detail
that may be useful
information?
Sadly, not really. I'm hoping some observers of this thread will chime
in.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
, for example, if there are
periodic jobs on master and they've just failed for a project, how
about just close the gate for that project until the failure
identified by the periodic job is fixed?
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
be
created _prior_ to implementation in an individual project?
* Is there prior art? What's a good format?
Thanks.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev
for which a generic tool should be
created _prior_ to implementation in an individual project?
* Is there prior art? What's a good format?
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent___
OpenStack-dev mailing list
there to some kind of middle ground. The
notes are at:
https://tank.peermore.com/tanks/cdent-rhat/SummitFunctionalTesting
TL;DR: death to `unittest` and _unit_ tests.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
(producers, consumers,
notifications) is easy.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
```
What transformation is needed to get similar functionality with
neutron?
Thanks.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
On Thu, 6 Nov 2014, Kyle Mestery wrote:
On Thu, Nov 6, 2014 at 1:24 PM, Chris Dent chd...@redhat.com wrote:
Using nova-networking I can make this work without issue:
```
[[local|localrc]]
HOST_IP=192.168.2.3
FLOATING_RANGE=192.168.2.128/26
```
What transformation is needed to get similar
.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Fri, 7 Nov 2014, Collins, Sean wrote:
On Fri, Nov 07, 2014 at 02:16:52PM CET, Chris Dent wrote:
What I hope to have at the end of this process is a nicely commented
local.conf that I can post somewhere for people who want a similar
thing.
Yes, and I hope my patchset will accomplish
/tanks/cdent-rhat/SummitFunctionalTesting
[2] And with luck will help create more effective and usable code[3].
[3] Yes, I believe in TDD.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
On Fri, 7 Nov 2014, John Davidge (jodavidg) wrote:
We’d like to gauge interest from the community on whether this is something
people want.
When I go to the existing network topology maps in horizon I
frequently find myself wanting to drag stuff around.
So +1 from me.
--
Chris Dent tw
interface to the router
- Add Neutron security group rules for ICMP and SSH
For devstack to live up to the dev in its name the above steps are
something I would expect devstack to do for me, assuming I set the
right varables and enabled the right services in local.conf.
--
Chris Dent tw
now and the only
reason I have any particular awareness of TC activities is because I
dig for it, hard.
I voted in this most recent election mostly for novelty, not because
I had a strong sense that I was engaging a representative process
that was going to impact direction.
--
Chris Dent tw
On Sun, 9 Nov 2014, Kashyap Chamarthy wrote:
On Sun, Nov 09, 2014 at 02:48:49PM +, Chris Dent wrote:
On Sat, 8 Nov 2014, Kashyap Chamarthy wrote:
[I realize you intend to use physical machine for DevStack, still I
thought I'd post this here.]
Thanks for posting it. Each added datapoint
great, but that's not here, on this list. This is where the
action is.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin
discussions?
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
.
If changing drivers is going to expose bugs and then lead to fixing
them, clearly we should be changing drivers frequently.
(Or to be less indirect: fragility in the face of timing changes is
a bug, let's look upon these things as positive opportunities to fix
things what lurk below.)
--
Chris Dent tw
actionable error responses
* setting not standards but guidelines for anything else
For most of that there is prior art and/or active conversation going
on outside the OpenStack world which ought to be useful fodder.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
all the paths?
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
On Tue, 3 Feb 2015, Everett Toews wrote:
On Feb 3, 2015, at 10:07 AM, michael mccune m...@redhat.com wrote:
On 02/02/2015 08:58 AM, Chris Dent wrote:
I think where we want to focus our attention is:
* strict adherence to correct HTTP
* proper use of response status codes
* effective
at server code, we do not help
ourselves or the users of our APIs by omitting this sort of thing.
+1
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
__
OpenStack Development Mailing List
should integrate with your
lastest release.
[1] Oh, my sides.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
that
increasing along?
[1]
http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-02-12-16.00.html
[2] This is a paraphase of:
http://tools.ietf.org/html/rfc7231#section-6.5.5
[3] https://pypi.python.org/pypi/gabbi
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks
On Thu, 12 Feb 2015, Flavio Percoco wrote:
On 11/02/15 11:24 +, Chris Dent wrote:
I think it is time we recognize and act on the fact that the corporate
landlords that pay many of us to farm on this land need to provide more
resources. This will help to ensure the health of semi-artifical
in the gate as a way of marshalling
resources.
Do I expect to see that happen? Sadly, not really.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
__
OpenStack Development Mailing List
challenging parts of the build, but the result has been
a lot of flexbility.
[2] https://pypi.python.org/pypi/wsgi_intercept
[3] https://pypi.python.org/pypi/jsonpath-rw
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
of ambiguity so to test them a lot of flexibility is required in
the tests. Already in conversations this evening people are asking for
more features in the evaluation of response bodies in order to be able
to test more flexibily.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com
discover gabbi |subunit-trace
[...]
gabbi.driver.test_intercept_self_inheritance_of_defaults.test_request
[0.027512s] ... ok
[...]
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
__
OpenStack
should have used:
http://developer.openstack.org/api-ref-telemetry-v2.html
[2] https://github.com/tiddlyweb/tiddlyweb/blob/master/tiddlyweb/urls.map
[3] http://lists.openstack.org/pipermail/openstack-dev/2015-January/054153.html
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com
changed.
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-January/054287.html
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent__
OpenStack Development Mailing List (not for usage
necessarily depend on what else might be in the
datastore used by the API. It needs to test that which it knows about.
I hope that clarifies things a bit.
[1] https://review.openstack.org/#/c/146187/2/ceilometer/gabbi/test_gabbi.py,cm
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com
.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
On Tue, 13 Jan 2015, Ian Cordasco wrote:
On 1/12/15, 17:21, Chris Dent chd...@redhat.com wrote:
On Mon, 12 Jan 2015, Ian Cordasco wrote:
This worked extremely well in my experience and helped improve
development
time for new endpoints and new endpoint versions. The documentation was
also
it)
* decisions get made by the people are who are present _now_ and no
others
(The second is obviously a more relevant problem.)
So: Yes please to logs, but no thank you to IRC being such a primary
medium of communication (which, in my experience, it has been in
OpenStack).
--
Chris Dent tw
1 - 100 of 758 matches
Mail list logo
