Sandy,
Apologies for not responding earlier, I am on vacation ATM. Responses
inline.
On 10/31/2013 08:13 AM, Sandy Walsh wrote:
On 10/30/2013 08:08 PM, Steven Dake wrote:
On 10/30/2013 12:20 PM, Sandy Walsh wrote:
On 10/30/2013 03:10 PM, Steven Dake wrote:
I will -2 any patch that adds
On Thu, Oct 31 2013, Monty Taylor wrote:
Sigh.
Yay We've added more competing methods of complexity!!!
Seriously. We now think that rabbit and zookeeper and mysql are ALL needed?
Yes, if you got synchronization problem that Paxos can resolve,
leveraging ZooKeeper is a good idea IMHO.
I looked at it once, but noticed its piggy backing on DNS infrastructure and
then wondered who has actually used this in production and didn't find much
info (except that it's a cornell project).
I never quite did get around to setting it up. Maybe u will have better luck :)
Sent from my
@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] Locking and ZooKeeper - a space oddysey
On 10/30/2013 03:10 PM, Steven Dake wrote:
I will -2 any patch that adds zookeeper as a dependency to Heat.
Certainly any distributed locking solution should be plugin based and
optional. Just
On Wed, Oct 30 2013, Clint Byrum wrote:
In the patch, there are two distributed lock drivers. One uses SQL,
and suffers from all the problems you might imagine a SQL based locking
system would. It is extremely hard to detect dead lock holders, so we
end up with really long timeouts. The other
On 31 окт. 2013 г., at 2:37, Clint Byrum cl...@fewbar.com wrote:
My point
is really that we should not care how serialization happens, we should
just express the work-flow, and let the underlying mechanisms distribute
and manage it as it is completed.
Sounds reasonable.
In this context,
On 10/30/2013 10:42 AM, Clint Byrum wrote:
So, recently we've had quite a long thread in gerrit regarding locking
in Heat:
https://review.openstack.org/#/c/49440/
In the patch, there are two distributed lock drivers. One uses SQL,
and suffers from all the problems you might imagine a
On 10/30/2013 08:08 PM, Steven Dake wrote:
On 10/30/2013 12:20 PM, Sandy Walsh wrote:
On 10/30/2013 03:10 PM, Steven Dake wrote:
I will -2 any patch that adds zookeeper as a dependency to Heat.
Certainly any distributed locking solution should be plugin based and
optional. Just as a
On 10/31/2013 11:43 AM, Monty Taylor wrote:
Yes. I'm strongly opposed to ZooKeeper finding its way into the already
complex pile of things we use.
Monty, is that just because the stack is very complicated now, or
something personal against ZK (or Java specifically)?
Curious.
-S
I'm pretty sure the cats out of the bag.
https://github.com/openstack/requirements/blob/master/global-requirements.t
xt#L29
https://kazoo.readthedocs.org/en/latest/
-Josh
On 10/31/13 7:43 AM, Monty Taylor mord...@inaugust.com wrote:
On 10/30/2013 10:42 AM, Clint Byrum wrote:
So, recently
Sigh.
Yay We've added more competing methods of complexity!!!
Seriously. We now think that rabbit and zookeeper and mysql are ALL needed?
Joshua Harlow harlo...@yahoo-inc.com wrote:
I'm pretty sure the cats out of the bag.
In the spirt of openness, yes I do think they are all needed.
If they are not supported, then openstack is not open, it is a closed
system.
We should strive to innovate, not strive to be stuck with the status quo.
To me it is a developers decision to pick the right solution, if that
solution
On 10/31/2013 01:32 PM, Joshua Harlow wrote:
In the spirt of openness, yes I do think they are all needed.
If they are not supported, then openstack is not open, it is a closed
system.
We should strive to innovate, not strive to be stuck with the status quo.
To me it is a developers
Agreed,
I don't think we should enforce a hard requirement for the same reason we
should avoid zookeeper.
To me they are the same, saying 'no ZK' is the same as saying 'only mysql
or rabbitmq'...
Both not so open.
On 10/31/13 11:04 AM, Monty Taylor mord...@inaugust.com wrote:
On 10/31/2013
So, recently we've had quite a long thread in gerrit regarding locking
in Heat:
https://review.openstack.org/#/c/49440/
In the patch, there are two distributed lock drivers. One uses SQL,
and suffers from all the problems you might imagine a SQL based locking
system would. It is extremely hard
Hi Clint,
I think you rose a point here. We implemented distributed engine in Murano
without locking mechanism by keeping state consistent on each step. We
extracted this engine from Murano and plan to put it as a part of Mistral
project for task management and execution. Working Mistral
To: openstack-dev openstack-dev@lists.openstack.org,
Date: 30/10/2013 07:45 PM
Subject:[openstack-dev] [Heat] Locking and ZooKeeper - a space
oddysey
So, recently we've had quite a long thread in gerrit regarding locking
in Heat:
https://review.openstack.org/#/c/49440
On 10/30/2013 10:42 AM, Clint Byrum wrote:
So, recently we've had quite a long thread in gerrit regarding locking
in Heat:
https://review.openstack.org/#/c/49440/
In the patch, there are two distributed lock drivers. One uses SQL,
and suffers from all the problems you might imagine a SQL based
Clint Byrum cl...@fewbar.com wrote on 10/30/2013 01:42:53 PM:
...
The engine should store _all_ of its state in a distributed data store
of some kind. Any engine should be aware of what is already happening
with the stack from this state and act accordingly. That includes the
engine
For taskflow usage/details: https://wiki.openstack.org/wiki/TaskFlow
Let me know if the documentation there is not sufficient about defining
who its useful so that I can make it more clear (to resolve the 'versed on
TaskFlow's details' part). As I have tried to define the use-cases that it
can
On 31 October 2013 06:42, Clint Byrum cl...@fewbar.com wrote:
So, recently we've had quite a long thread in gerrit regarding locking
in Heat:
https://review.openstack.org/#/c/49440/
In the patch, there are two distributed lock drivers. One uses SQL,
and suffers from all the problems you
So afaik hbase recommends.
http://hbase.apache.org/book/zk.sasl.auth.html
It doesn't integrate with keystone, but that¹s expected ;)
-Josh
On 10/30/13 11:25 AM, Robert Collins robe...@robertcollins.net wrote:
On 31 October 2013 06:42, Clint Byrum cl...@fewbar.com wrote:
So, recently we've
As for the mutex and locking and all that problem.
I would expect locking to be a necessity at some point for openstack.
Even if the state transitions are the locks themselves (that¹s still a
lock by another name imho) and u need a reliable way to store and change
those state transitions (aka
On Oct 30, 2013, at 11:11 AM, Alex Glikson glik...@il.ibm.com wrote:
There is a ZK-backed driver in Nova service heartbeat mechanism
(https://blueprints.launchpad.net/nova/+spec/zk-service-heartbeat) -- would
be interesting to know whether it is widely used (might be worth asking at
the
On 10/30/2013 03:10 PM, Steven Dake wrote:
I will -2 any patch that adds zookeeper as a dependency to Heat.
Certainly any distributed locking solution should be plugin based and
optional. Just as a database-oriented solution could be the default plugin.
Re: the Java issue, we already have
Has anyone looked into using concoord for distributed locking?
https://pypi.python.org/pypi/concoord
Best,
-jay
On 10/30/2013 02:39 PM, Joshua Harlow wrote:
So my idea here was that to break the abstraction for heat into 3 parts.
Pardon my lack of heat terminology/knowledge if I miss
Has anyone looked at any lock-free solution?
-Original Message-
From: Sandy Walsh [mailto:sandy.wa...@rackspace.com]
Sent: Wednesday, October 30, 2013 12:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] Locking and ZooKeeper - a space oddysey
On 10/30
Excerpts from Joshua Harlow's message of 2013-10-30 11:57:30 -0700:
As for the mutex and locking and all that problem.
I would expect locking to be a necessity at some point for openstack.
Even if the state transitions are the locks themselves (that¹s still a
lock by another name imho) and
Doh, sorry, left out the important part I had originally intended.
The ZK unit tests could be split to not run by default, but if you're a
ZK shop ... run them yourself. They might not be included in the gerrit
tests, but should be the nature with heavy-weight drivers.
We need to do more of this
On 31 October 2013 08:37, Sandy Walsh sandy.wa...@rackspace.com wrote:
Doh, sorry, left out the important part I had originally intended.
The ZK unit tests could be split to not run by default, but if you're a
ZK shop ... run them yourself. They might not be included in the gerrit
tests, but
+1 ;)
On 10/30/13 12:37 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Joshua Harlow's message of 2013-10-30 11:57:30 -0700:
As for the mutex and locking and all that problem.
I would expect locking to be a necessity at some point for openstack.
Even if the state transitions are
On 10/30/2013 01:34 PM, Joshua Harlow wrote:
To me u just made state consistency be a lock by another name.
A lock protects a region of code from being mutually accessed
Personally I view a lock as protecting a set of data from being mutually
accessed.
The question to me becomes what
On 10/30/2013 04:44 PM, Robert Collins wrote:
On 31 October 2013 08:37, Sandy Walsh sandy.wa...@rackspace.com wrote:
Doh, sorry, left out the important part I had originally intended.
The ZK unit tests could be split to not run by default, but if you're a
ZK shop ... run them yourself. They
On 30/10/13 15:27 -0400, Jay Pipes wrote:
Has anyone looked into using concoord for distributed locking?
https://pypi.python.org/pypi/concoord
Looks interesting!
-Angus
Best,
-jay
On 10/30/2013 02:39 PM, Joshua Harlow wrote:
So my idea here was that to break the abstraction for heat
This works as long as you have 1 DB and don't fail over to a secondary
slave DB.
Now u can say we all must use percona (or similar) for this, but then
that¹s a change in deployment as well (and imho a bigger one). This is
where the concept of a quorum in zookeeper comes into play, the
transaction
Excerpts from Joshua Harlow's message of 2013-10-30 17:46:44 -0700:
This works as long as you have 1 DB and don't fail over to a secondary
slave DB.
Now u can say we all must use percona (or similar) for this, but then
Did you mean Galera which provides multiple synchronous masters?
that¹s
Yup, galera, thx! :)
As for the:
It also doesn't handle the case where u can automatically recover from the
current resource owner (nova-compute for example) dying.
So heat is actively working on some resources, doing its thing, its binary
crashes (or kill -9 occurs), what happens? The same
37 matches
Mail list logo
