" or "os-integration-tests".
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
ht
hat can 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
gainst 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.o
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
ach sample 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:c
l those potentially good reasons there's 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 mailin
ll make it possible to do more 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
___
in the project and make some contributions? That is how 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
ot;in tree 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...
--
Chri
(e.g. getting more nodes for CI, having more 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
[1] I do think, when using namespaces, that you must have a namespace
for the extensions different from whatever the thing being
extended is using.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenS
x27;d _love_ to be more capable at gate debugging.
That said, it does get easier just by doing it. The first many times
is like beating my head against the wall, especially the constant
sense of where am I and where do I need to go.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermor
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
t, some discussion here on options to reach some
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
that
existing notification use cases 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
to understand more clearly what's going on. My interest here 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
___
x27;t know) that having more granularity in projects will
allow different teams to engage at different rates and thus get stuff
done, but I do not think it will do much with regard to external
perceptions of quality. That's going to take a much different kind of
work and attention.
--
Chris Den
t of automated
hook?
Thoughts? Anybody wanna hack 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:@anticde
o put all this another way: As we are evaluating what we want to do
and how we want to do it we need 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/piper
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/
o the existential questions 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
notifications 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:cd
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 free
pproved) way to do 'make clean'.
I guess tox -eclean or something would be the same but it feels
wrong somehow.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
OpenStack-dev mailing list
OpenStack-dev@lists.o
enstack.org/#/c/614896/>
Placement role for ansible project config
* <https://review.openstack.org/#/c/614285/>
hyperv bump placement version
# End
Apologies if this is messier than normal, I'm rushing to get it out
before I travel.
--
Chris Dent ٩◔̯◔۶
t seems like Eric and Jay are probably best situated to define
and refine what should really be going on with the resource
tracker and other actions on the compute-node.
* We need to have further discussion and investigation on
allocations getting out of sync. Volunteers?
What else?
[1] https:/
rom there start gathering up
information about the services and then their endpoints.
All of that seems of one piece to me and there should be one way to
do it.
But in the absence of that, this is a good plan.
What do people think?
I think cats are nice and so is this plan.
ople who want to use our code. Will it
cause breakage and extra work us now? Possibly, but it's like making
an early payment on the mortgage: We are saving cost later.
--
Chris Dent ٩◔̯◔۶ https://anticdent.org/
freenode: cdent
with infrastructure like subunit and testrepository was one of
the most 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
--
Ch
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
re's a sample of the output from running gabbi's own gabbi
tests:
$ python -m subunit.run 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.c
k.org/developer/ceilometer/webapi/v2.html
but I think I 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
es the HTTP tests. A long
running test cannot 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
--
ocumented as they’re 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
On Tue, 13 Jan 2015, Ian Cordasco wrote:
On 1/12/15, 17:21, "Chris Dent" 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 heavil
ere in
the body.
--
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:u
if you try
to be good about ignoring 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
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 (not for
my master 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)
U
on of truth and using breakage 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 Dev
it is
somebody else's problem.
--
Chris Dent
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
sues than these, but I think some of
the above is being left out of the discussion, and this message
needs 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
#x27;s 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 lis
ere, just point out
a good 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 m
f-notifications
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't gain much if you have people in a room with name A and all
you do is put 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
pporunities throughout
OpenStack, not just in telemetry/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:/
On Mon, 25 Aug 2014, Joe Gordon wrote:
On Mon, Aug 4, 2014 at 3:29 AM, Chris Dent 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 of these.
ormation
about themselves.
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.
--
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://tan
lling on other stuff to do the work.
--
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
hat 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.co
thing 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
ity.
I think we should strive to worry less about 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
__
thing).
--
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
e the UI for
people who want to do things with the data.
So from my perspective, with regard to naming IPMI (and other hardware
sensor) related samples, I 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:@ant
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 usef
ensor 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.openstac
if easy to feel. So, 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
a generic tool should 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-
ojects have similar ideas in progress?
* Is this concept something 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/cden
n go from 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.
new stuff (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
cal|localrc]]
HOST_IP=192.168.2.3
FLOATING_RANGE=192.168.2.128/26
```
What transformation is needed to get similar functionality with
neutron?
Thanks.
--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent
___
On Thu, 6 Nov 2014, Kyle Mestery wrote:
On Thu, Nov 6, 2014 at 1:24 PM, Chris Dent 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 functionality with
come that problem...disco.
--
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 this
est suites are ever run by robots.
[1] https://tank.peermore.com/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
_
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
te network 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.con
year 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 De
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 data
at's 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.opensta
x27;s
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
on.
What's 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
___
ill javelin have any knowledge of whether the
current 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.open
new features
and functionality to it.
I'll press 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:@an
knowledge is being represented is
code. 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__
y
with a pre-warmed 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 mailin
rmat, we could have said,
in response to the initial proposal, "looks good but if you make the
data look like _this_ that would be totally wicked 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
ome configured mapping rules?
I don't think there needs to be much, if any, mapping on the consumption
side of the notification process if there is a standard form in which
those notifications are emitted. In those cases where pipeline
transformation needs to be done ( multiple valu
de 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.
it is Ceilometer then it means that StackTach must also
keep its own mapping. And so does every other consumer. The general
provision here is to get more DRY about information authority.
If you can figure out how to do that in a concrete way ... then great,
I'd be receptive, let's hear s
ke to see this move along 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
ith what's being used.
This feels like something that we should be thinking about with an eye
to the K* cycle - would you agree?
Yup.
Thanks for helping to tease this all out and provide some direction on
where to go next.
--
Chris Dent tw:@anticde
once landed -
https://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:/
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 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 time. Seems like that will hurt parallelism
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-
tely informative) failure
than '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 freenod
tionsIKnow) as exc:
LOG.warning('shame, no workie, but you know, it happens: %s', exc)
except Exception:
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 De
d do in that small
environment (rather than the overwhelming 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
pa
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:
ash around you.
Maybe you aren't looking at the most recent 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
(witho
f you get back to me by tomorrow morning (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://list
to get their opinions 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:/
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. If
ter/objectstore/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/
ght argument,
either from 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 b
f the swift dependencies
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.openstac
:
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
1 - 100 of 771 matches
Mail list logo
