<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 4, 2015 at 8:44 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@outlook.com" target="_blank">harlowja@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Flavio Percoco wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/08/15 19:48 +0200, Gorka Eguileor wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Aug 03, 2015 at 03:42:48PM +0000, Fox, Kevin M wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm usually for abstraction layers, but they don't always pay off<br>
very well due to catering to the lowest common denominator.<br>
<br>
Lets clearly define the problem space first. IFF the problem space<br>
can be fully implemented using Tooz, then lets do that. Then the<br>
operator can choose. If Tooz cant and wont handle the problem space,<br>
then we're trying to fit a square peg in a round hole.<br>
</blockquote>
<br>
What do you mean with clearly define the problem space? We know what we<br>
want, we just need to agree on the compromises we are willing to make,<br>
use a DLM and make admins' life a little harder (only for those that<br>
deploy A-A) but have an A-A solution earlier, or postpone A-A<br>
functionality but make their life easier.<br>
<br>
And we already know that Tooz is not the Holy Grail and will not perform<br>
the miracle of giving Cinder HA A-A. It is only a piece of the problem,<br>
so there's nothing to discuss there, and it's not a square peg on a<br>
round hole, because it fits perfectly for what it is intended. But once<br>
you have filled that square hole you need another peg, the round one for<br>
the round hole.<br>
<br>
If people are expecting to find one thing that fixes everything and<br>
gives us HA A-A on its own, then I believe they are a little bit lost.<br>
</blockquote>
<br>
As confusing as it seems, we've now moved from talking about just<br>
Cinder to understanding whether this is a problem many projects have<br>
and whether we can find a solution that will work for most of them.<br>
Therefore, I've renamed this thread to make this more evident.<br>
<br>
Now, so far we have:<br>
<br>
- Ironic has an internal distributed lock and it uses a hash-ring<br>
- Ceilometer uses tooz<br>
- Several projects use a file lock of some other fashion of<br>
distributed lock.<br>
- *Add yours here*<br>
<br>
Each one of these projects has a specific use-case that doesn't<br>
necessarily overlap. I'd like to see those cases listed somewhere.<br>
We've done this in the past already and I believe we can do it now as<br>
well. As I've mentioned in another thread, Gorka has done this for<br>
Cinder already now we need to do it for other services too. Even if<br>
your project has a DLM in place, it'd be good to know what problem you<br>
solved with it as it may be a problem that other projects have as<br>
well.<br>
<br>
As a community, we've been able to do away with adding a new service<br>
for DLM's thus far. I'm not saying we don't need one but, as mentioned<br>
in other threads, lets give this some more thought before we add a new<br>
service that'll make deploying and maintaining OpenStack harder.<br>
<br>
</blockquote>
<br>
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).<br><br></blockquote><div><br></div><div>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.<br><br></div><div>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...<br><br></div><div>--Morgan <br></div></div></div></div>