.
--
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
.
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
/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
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
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
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
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 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
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 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
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
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
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
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
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
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
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
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
.
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
, 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
/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
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
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
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
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
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
:
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
'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
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
://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
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
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
. 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
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
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
else's problem.
--
Chris Dent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
701 - 758 of 758 matches
Mail list logo
