Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consul proof-of-concept backend #166

Merged
merged 7 commits into from Dec 15, 2015
Merged

Consul proof-of-concept backend #166

merged 7 commits into from Dec 15, 2015

Conversation

stalehd
Copy link
Contributor

@stalehd stalehd commented Dec 9, 2015

A consul backend for Cloudname. Note that this pull request depends on another pull request. I expect rebasing to happen. Note that the entire Consul implementation is done i in the latest commit.

Ståle Dahl and others added 5 commits November 12, 2015 18:03
Rewrite into a core library with simple methods and an abstraction layer on
top of the backend system.

The following backends are implemented
* Memory (for testing; only works within a single JVM)
* ZooKeeper (proof-of-concept implementation of the backend)

The following libraries are created:
* Service discovery library

This brings the overall functionality on par with 2.x with a few exceptions:
* Locking isn't implemented. That did not work for the old library so
  there's no real change in functionality
* It isn't possible to query *everything* from a client. This will be
  addressed in another commit (or just ignored completely since the
  backends offers this in some shape or form)
* It isn't possible to resolve coordinates partially, f.e. finding
  "logserver" when your own coordinate is "service.tag.region";
  "logserver" should resolve to "logserver.tag.region". This will
  be solved in a later commit by making a separate resolver class that
  creates service coordinates based on existing coordinates.
* Javadoc: Spelling errors, inconsistent puncutation
* Tests: assertThat(<something>, is(equalTo(<other>)))
  rather than assertThat(<something>.equals(<other>), is(false))
* Use Array.deepEquals() in CloudnamePath
5ms is a little bit too quick for Core i5 and lesser processors. Be nice
and increase the time to 100ms. This is a lot so most backends should
(or rather, *must*) manage this.
Use a connection URL to create backends via the BackendManager class.
This makes for a much easier way of creating different backends.
Use forEach() - much cleaner implementation.
This is a working Consul backend for Cloudname but it hasn't been tested
a lot. In short it creates a session which is kept alive by regular polls
to the Consul Agent. The session is then used to create ephmeral KV entries.

Permanent leases are just regular KV entries without an associated session.

Note that this implementation isn't tested in a real life production
environment and that the defaults are most likely a bit too aggressive for
to be used as is. In particular the polling when a watch gets 404 is very
aggressive and the lock-delay parameter is set to 0.

There's no integration with the service catalog in Consul either since that
is handled on a higher level in Cloudname. This might require a slight change
in the core API with some sort of hooks or custom service implementation on
top of Cloudname. A custom service implementation isn't ideal.

The backend tests are also updated a bit with more generous backend propagation
timeouts throughout.
stalehd added a commit that referenced this pull request Dec 15, 2015
Consul backend. Not production ready yet but neither is Cloudname.
@stalehd stalehd merged commit 986b036 into Cloudname:master Dec 15, 2015
@stalehd stalehd deleted the consul branch December 15, 2015 22:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants