Lock module replacement?

[Ask Bjørn Hansen]

The lock and leader modules are "deprecated" in 0.4.x, but it seems like "deprecated" means "removed", or did I miss a switch?

$ curl -L http://127.0.0.1:4001/mod/v2/lock/mylock -XPOST -d ttl=20

404 page not found

Is there a simple idiom for doing locks and leader elections without the modules? (Doing this is our primary use case really).

Ask

[Brandon Philips]

On Fri, May 30, 2014 at 3:15 PM, Ask Bjørn Hansen <a...@develooper.com> wrote:
> Is there a simple idiom for doing locks and leader elections without the
> modules? (Doing this is our primary use case really).

The code that does the lock and leader election is all built on top of
go-etcd. It is all straight forward code:

https://github.com/coreos/etcd/tree/master/mod/lock/v2

Thanks,

Brandon

[Dustin Oprea]

Wasn't the point of adding the modules more about convenience and encapsulating common patterns inside of an API to reduce risk/duplication?

The implementations of locking and such are heretofore the responsibility of the consuming application?

Dustin

 

Thanks,

Brandon

--
You received this message because you are subscribed to the Google Groups "etcd-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to etcd-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Darren Shepherd]

I have to also say I ways a bit surprised that the lock mod was deprecated.  I saw that as a big advantage over zookeeper.  Locking in ZK is done using a documented recipe, but they're are tons of caveats and it's easy to mess up the implementation of the recipe.  As such you really shouldn't use ZK unless you also use a robust client that implements the recipes like Netflix/Apache Curator.

So I feel dropping the lock mod is step backwards in terms of the simplicity that etcd provided.  At least it should be clearly shown on the etcd documentation how to do locking using CAS and document anything clients should be aware of.  For example how to detect that the lock owner is dead so another client should take over.  

Darren

[Yicheng Qin]

This is excerpted from our Documentation/modules.md:
```
**Warning**: Modules are deprecated from v0.4 until we have a solid base we can apply them back onto.
For now, we are choosing to focus on raft algorithm and core etcd to make sure that it works correctly and fast.
And it is time consuming to maintain these modules in this period, given that etcd's API changes from time to time.
Moreover, the lock module has some unfixed bugs, which may mislead users.
But we also notice that these modules are popular and useful, and plan to add them back with full functionality as soon as possible.
```

We treat the lock/leader/dashboard modules a very important part of etcd, and we would more than like to maintain them and even add new modules to make etcd easier to use. For the project, our best wish is to make developers feel etcd is powerful and easy to use.
But we find some serious bugs in modules in 0.3 version, and this would make things go wrong. This is rather terrible to provide some wrong functionality to users. We have discussed about this seriously and thoroughly, and make the decision to deprecate it because it really needs some time. We are working hard to make it back soon.

Thanks!

Yicheng

[Ask Bjørn Hansen]

Is it the module infrastructure or the specific lock implementation that is wrong/broken/dangerous? And if so, what are the failure conditions?

Ask

-- 

http://askask.com/

You received this message because you are subscribed to a topic in the Google Groups "etcd-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/etcd-dev/ubcPWuL8wSg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to etcd-dev+u...@googlegroups.com.

[Michael Piefel]

Am 02.06.2014 20:43, schrieb Yicheng Qin:

We treat the lock/leader/dashboard modules a very important part of etcd, and we would more than like to maintain them and even add new modules to make etcd easier to use. For the project, our best wish is to make developers feel etcd is powerful and easy to use.

I believe no-one cares the slightest whether these are modules or what-not. For me, important functionality is missing. The dashboard was broken already, now lock and leader are gone. In fact, etcd is not powerful.

Also, etcd is not easy to use. The threads here such as “Cluster down, cannot restart” prove it. I have the feeling that for my use case, I bet on the wrong horse.

Greetings,
   Michael

[Peter Woodman]

re: easy to use- i dare you to use zookeeper instead. speaking from an
org with scars.

[Brandon Philips]

On Mon, Jun 2, 2014 at 5:37 PM, Ask Bjørn Hansen <a...@develooper.com> wrote:
> Is it the module infrastructure or the specific lock implementation that is
> wrong/broken/dangerous? And if so, what are the failure conditions?

The internal implementation of the lock is fine AFAIK. We removed it
because the lock API wasn't as helpful as we originally hoped. We
wanted to get a better feeling for what would be useful before
committing to having the lock module as a permanent feature.

Thanks

Brandon

[Brandon Philips]

On Mon, Jun 2, 2014 at 11:41 PM, Michael Piefel
<Michael...@xx-well.com> wrote:
> I believe no-one cares the slightest whether these are modules or what-not.
> For me, important functionality is missing.

What important functionality is missing for you?

> Also, etcd is not easy to use. The threads here such as “Cluster down,
> cannot restart” prove it. I have the feeling that for my use case, I bet on
> the wrong horse.

Are you using 0.4.1? When are you encountering this unexpectedly? Can
you please file a bug?

Thanks,

Brandon

[Dustin Oprea]

For me, it's all about the simplicity of the RAFT algorithm, and both the hierarchical nature of nodes and being able to longpoll on them.

I don't know how long you've actually been stewing and waiting to explode on this subject, but these modules, at least locking and leader election, were very, very new. They were only available for a few months, and the principal development team has expressed, since the beginning, that they were only modules of convenience.  I'm disappointed just as much as anyone that they're gone. However, the team, who has shown themselves to always be concerned with elegance and stability more than any other metric, had concerns about compromising the platform and obviously thought that the inconvenience of removing it didn't compare to the disservice of leaving it.

All of this being said, the platform is still "unreleased", and not recommended for production. So, buyer-beware.

If you want something that's good for production, install Java, install HK, and have at it. After you've decided to abandon HK, you'll want to write your own solution (like all HK users want to, eventually). However, you'll just find yourself start duplicating etcd. Then, you'll decide that maybe it'll be in your best interest to survive with etcd by simply remaining patient and applying the updates until the guys release 1.0 (which I believe should be later this year.. http://coreos.com/blog/etcd-The-Road-to-1.0).

So, just cut to the end and appreciate etcd for what it is: not ready, but worth the wait.

Dustin

[Roy Smith]

I'm with Dustin.  I looked at the various offerings in this space, and came to the conclusion that none of them were perfect.  That left me with having to pick between the last generation of solutions (ZooKeeper, etc), and looking at a promising new project which (as my experiences reported under the "Cluster down, cannot restart" thread attest to), is clearly not ready for prime time yet.  But, the guys working on it don't claim it's ready for prime time, so what's to complain about?

Given a choice between "heavyweight legacy solution that has known problems which it's never going to evolve past", and "shiny new toy which probably has lots of unknown problems, but is under development", I'll go with shiny new toy.  For my situation, I don't need something that works today.  I can afford to play around with bleeding edge code and bide my time until 1.0 comes out.  If you have more immediate needs, this may not be the right path for you.

The jury is still out on whether Go will win the hearts and minds of enough people to become a major language, but that's all part of the shiny new toy syndrome.

--

Roy Smith

r...@panix.com

[Michael Piefel]

Am 03.06.2014 17:04, schrieb Dustin Oprea:

>
> I don't know how long you've actually been stewing and waiting to

> explode on this subject, […]
>

I didn’t mean to explode, and if it got across that way, I’m sorry.

At my company, we wanted to use a configuration database. An implementation using the standard database (Oracle, in this case) via JDBC was already prototyped. Some wanted Redis. I voted for etcd. Knowing that the selection would stick for years, I pushed that even though it was far from version 1.0. Availability of both Oracle and Redis was always considered to be good enough, even if that is a single point of failure. In a Java-only world REST is not much easier than accessing a relational database. Reasons I came up with for etcd were in fact the locking and the dashboard.

This might explain my disappointment.

So long,
   Michael