Any progress on this?
Let me know and if not I can throw something together to (if you are
busy or pre-occupied, or other) :)
-Josh
Joshua Harlow wrote:
Feel free to add it, or open a blueprint, or make a spec to :)
Any of the above are ok with me.
I did start prototyping something @
Gorka Eguileor wrote:
On Thu, May 28, 2015 at 10:51:35AM -0700, Joshua Harlow wrote:
Btw, if u *do not* want to do a spec (using [1]) or blueprint let me know
and I'll probably make a spec so that we can ensure (and agree on) the
semantics of this because the specifics of what 'cancel' or
Btw, if u *do not* want to do a spec (using [1]) or blueprint let me
know and I'll probably make a spec so that we can ensure (and agree on)
the semantics of this because the specifics of what 'cancel' or 'abort'
means start to matter.
[1]
Please add it Gorka.
thanks,
dims
On Thu, May 28, 2015 at 6:23 AM, Gorka Eguileor gegui...@redhat.com wrote:
On Wed, May 27, 2015 at 08:47:42AM -0400, Davanum Srinivas wrote:
Hi Team,
Here are the etherpads from the summit[1].
I remember that in Taskflow's Fishbowl session we discussed not
Flavio,
PIka is an unknown quantity at the moment as none of us have touched
it. It was brought up by rabbitmq folks. So someone should look at it.
We don't have have enough info either to say we should use Pika by
itself or as a kombu driver. We may have to make that determination at
some point
On 27/05/15 10:24 -0700, Joshua Harlow wrote:
Thanks dims!
indeed, thanks.
[snip]
Also for the pika one, I'd really like to understand why not kombu. I
don't know enough of the background, but from that session it looks
like we need to do some comparative analysis (and imho get feedback
On Wed, May 27, 2015 at 08:47:42AM -0400, Davanum Srinivas wrote:
Hi Team,
Here are the etherpads from the summit[1].
I remember that in Taskflow's Fishbowl session we discussed not only
pause/yield option but abort/cancel for long running tasks as well, but
reviewing the Etherpad now I don't
On 28/05/15 07:34 -0400, Davanum Srinivas wrote:
Flavio,
PIka is an unknown quantity at the moment as none of us have touched
it. It was brought up by rabbitmq folks. So someone should look at it.
We don't have have enough info either to say we should use Pika by
itself or as a kombu driver. We
Flavio,
yay! :)
-- dims
On Thu, May 28, 2015 at 9:24 AM, Flavio Percoco fla...@redhat.com wrote:
On 28/05/15 07:34 -0400, Davanum Srinivas wrote:
Flavio,
PIka is an unknown quantity at the moment as none of us have touched
it. It was brought up by rabbitmq folks. So someone should look at
Feel free to add it, or open a blueprint, or make a spec to :)
Any of the above are ok with me.
I did start prototyping something @
https://review.openstack.org/#/c/184663/ (external cancellation) but it
might be going in the wrong direction (or a different direction); so
feel free to
Josh,
thanks. yes, the kombu vs pika is just a research thing someone should
look at. no blueprint, no spec, so not approved in anyway :)
-- dims
On Wed, May 27, 2015 at 1:24 PM, Joshua Harlow harlo...@outlook.com wrote:
Thanks dims!
Good write up,
Other things I noted (more controversial
Thanks dims!
Good write up,
Other things I noted (more controversial ones); is that we need to come
up with a concurrency strategy (and/or guidelines, and/or best
practices). At least I feel this will be a way that works and imho
implies that one concurrency strategy will (likely) not fit
12 matches
Mail list logo
