Morgan Fainberg wrote:
On Tue, Aug 4, 2015 at 8:44 AM, Joshua Harlow <harlo...@outlook.com <mailto:harlo...@outlook.com>> wrote: Flavio Percoco wrote: On 03/08/15 19:48 +0200, Gorka Eguileor wrote: On Mon, Aug 03, 2015 at 03:42:48PM +0000, Fox, Kevin M wrote: I'm usually for abstraction layers, but they don't always pay off very well due to catering to the lowest common denominator. Lets clearly define the problem space first. IFF the problem space can be fully implemented using Tooz, then lets do that. Then the operator can choose. If Tooz cant and wont handle the problem space, then we're trying to fit a square peg in a round hole. What do you mean with clearly define the problem space? We know what we want, we just need to agree on the compromises we are willing to make, use a DLM and make admins' life a little harder (only for those that deploy A-A) but have an A-A solution earlier, or postpone A-A functionality but make their life easier. And we already know that Tooz is not the Holy Grail and will not perform the miracle of giving Cinder HA A-A. It is only a piece of the problem, so there's nothing to discuss there, and it's not a square peg on a round hole, because it fits perfectly for what it is intended. But once you have filled that square hole you need another peg, the round one for the round hole. If people are expecting to find one thing that fixes everything and gives us HA A-A on its own, then I believe they are a little bit lost. As confusing as it seems, we've now moved from talking about just Cinder to understanding whether this is a problem many projects have and whether we can find a solution that will work for most of them. Therefore, I've renamed this thread to make this more evident. Now, so far we have: - Ironic has an internal distributed lock and it uses a hash-ring - Ceilometer uses tooz - Several projects use a file lock of some other fashion of distributed lock. - *Add yours here* Each one of these projects has a specific use-case that doesn't necessarily overlap. I'd like to see those cases listed somewhere. We've done this in the past already and I believe we can do it now as well. As I've mentioned in another thread, Gorka has done this for Cinder already now we need to do it for other services too. Even if your project has a DLM in place, it'd be good to know what problem you solved with it as it may be a problem that other projects have as well. As a community, we've been able to do away with adding a new service for DLM's thus far. I'm not saying we don't need one but, as mentioned in other threads, lets give this some more thought before we add a new service that'll make deploying and maintaining OpenStack harder. On the contrary, I think it would make deploying and maintaining openstack easier... As each service implements its own DLM pieces this means that they all do it in a way that is different from each other, which actually makes the situation worse (now operators needs to figure out the X different ways this was done, the X different ways to release a messed up/stale/other lock...). DLM(s) like zookeeper and others provide that 'single' way of doing it (they also provide introspection abilities, ie to see who is waiting on a lock, what connection has a lock...) so IMHO I feel the question of should we has really already been passed (but others may disagree). I strongly agree that we are past the point of needing a DLM. We have mostly papered over the missing choice of a consistent DLM across projects with many different implementations. I'm all for picking a DLM that is consistent across all of OpenStack and help our deployers and operators only need to know one of these technologies. A single use of a DLM should not inflame the "technology proliferation" argument as long as we can be opinionated on the one we use and test against. Is the next step something x-project outlining the choices/direction so we can start that phase of the conversation? I am sure that once we have a clear direction, more and more use-cases will come out of the woodwork...
I can start a cross-project spec tomorrow if people feel that is useful, it may be slightly opinionated (I am one of the cores that works on https://kazoo.readthedocs.org/ so I am going be slightly biased for obvious reasons).
--Morgan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
