Consul

Consul

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

Hi Ceph,

While at the OpenStack summit Dan Bode spoke highly of Consul ( https://consul.io/intro/index.html ). Its scope is new to me. Each individual feature is familiar but I'm not entirely sure if combining them into a single software is necessary. And I wonder how it could relate to Ceph. It is entirely possible that it does not even make sense to ask theses questions ;-)

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Consul

[Hunter Nield]

I concur with Dan on Consul. It's a great tool.

We use Consul in our Ceph environments but only as a layer above an
installed Ceph installation. Health checks (for the mons/osds
processes and ceph health) and service discovery (for the
apps/services that run in Docker containers on top). We've started on
an alerting tool if anyone has use for it -
https://github.com/AcalephStorage/consul-alerts

There is definitely some overlap on the cluster consensus side (Paxos
vs Raft) and would be nice to reduce another moving part in our
cluster but I would imagine the projects are too different internally
to really combine the two of them.

The one thing that we'd wished for in Ceph before Consul existed was
an easily accessible distributed KV store. Ceph has parts of it but
exposing something like that with an easy CLI/REST API might provide
the primitives for building higher level functionality that Consul
provides. More than likely a distraction though since Consul does such
a good job now.

On a side note, I haven't spoken to Dan in a while but curious on his
thoughts on the overlap on Consul in config management land. Service
discovery, remote execution, etc have some overlap in Puppet, Chef,
etc. Related to Ceph we're pondering it as alternative for deploying
mons/osds (larger scale ceph-deploy perhaps)

On Wed, Nov 5, 2014 at 8:38 AM, Loic Dachary <loic@dachary.org> wrote:
> Hi Ceph,
>
> While at the OpenStack summit Dan Bode spoke highly of Consul ( https://consul.io/intro/index.html ). Its scope is new to me. Each individual feature is familiar but I'm not entirely sure if combining them into a single software is necessary. And I wonder how it could relate to Ceph. It is entirely possible that it does not even make sense to ask theses questions ;-)
>
> Cheers
>
> --
> Loïc Dachary, Artisan Logiciel Libre
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Consul

[Loic Dachary]

[-- Attachment #1: Type: text/plain, Size: 3011 bytes --]

Hi,

On 05/11/2014 04:05, Hunter Nield wrote:
> I concur with Dan on Consul. It's a great tool.
> 
> We use Consul in our Ceph environments but only as a layer above an
> installed Ceph installation. Health checks (for the mons/osds
> processes and ceph health) and service discovery (for the
> apps/services that run in Docker containers on top). We've started on
> an alerting tool if anyone has use for it -
> https://github.com/AcalephStorage/consul-alerts
> 
> There is definitely some overlap on the cluster consensus side (Paxos
> vs Raft) and would be nice to reduce another moving part in our
> cluster but I would imagine the projects are too different internally
> to really combine the two of them.
> 
> The one thing that we'd wished for in Ceph before Consul existed was
> an easily accessible distributed KV store. Ceph has parts of it but
> exposing something like that with an easy CLI/REST API might provide
> the primitives for building higher level functionality that Consul
> provides. More than likely a distraction though since Consul does such
> a good job now.

I guess using radosgw with the S3/Swift API is close enough in terms of what Consul needs to store key/values. But maybe I don't understand what you mean by "easily accessible distributed KV store" and wrongly assume radosgw is easy enough ;-) 

> On a side note, I haven't spoken to Dan in a while but curious on his
> thoughts on the overlap on Consul in config management land. Service
> discovery, remote execution, etc have some overlap in Puppet, Chef,
> etc. Related to Ceph we're pondering it as alternative for deploying
> mons/osds (larger scale ceph-deploy perhaps)

Is there a framework for integration tests of some kind in Consul ? Although https://github.com/puppetlabs/beaker/ provides that for puppet, it is still rarely used and it is painful because even when used to develop a module, it is likely to break in unpredictable ways because module dependencies have no integration tests and suffer from frequent regressions. It would be great to see modern tools such as Consul encourage a more robust approach to integration tests with proper tooling from the start.

Cheers

> On Wed, Nov 5, 2014 at 8:38 AM, Loic Dachary <loic@dachary.org> wrote:
>> Hi Ceph,
>>
>> While at the OpenStack summit Dan Bode spoke highly of Consul ( https://consul.io/intro/index.html ). Its scope is new to me. Each individual feature is familiar but I'm not entirely sure if combining them into a single software is necessary. And I wonder how it could relate to Ceph. It is entirely possible that it does not even make sense to ask theses questions ;-)
>>
>> Cheers
>>
>> --
>> Loïc Dachary, Artisan Logiciel Libre
>>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Consul

[Sage Weil]

On Wed, 5 Nov 2014, Hunter Nield wrote:
> I concur with Dan on Consul. It's a great tool.
> 
> We use Consul in our Ceph environments but only as a layer above an
> installed Ceph installation. Health checks (for the mons/osds
> processes and ceph health) and service discovery (for the
> apps/services that run in Docker containers on top). We've started on
> an alerting tool if anyone has use for it -
> https://github.com/AcalephStorage/consul-alerts
> 
> There is definitely some overlap on the cluster consensus side (Paxos
> vs Raft) and would be nice to reduce another moving part in our
> cluster but I would imagine the projects are too different internally
> to really combine the two of them.
> 
> The one thing that we'd wished for in Ceph before Consul existed was
> an easily accessible distributed KV store. Ceph has parts of it but
> exposing something like that with an easy CLI/REST API might provide
> the primitives for building higher level functionality that Consul
> provides. More than likely a distraction though since Consul does such
> a good job now.

Have you seen the kv storage service provided by the mons?  It's pretty 
basic but is intended for stashing arbitrary config data.  The original 
use-case we wanted it for was storing the encryption keys for dm-cypt (you 
can restrict individual ceph entities to a subset of the config-key 
namespace), but we never got around to finishing that work (dm-crypt keys 
are still stored in /etc/ceph/keys/ on the local node until we find a 
vocal user with clear requirements).

config-key del <key>                     delete <key>
config-key exists <key>                  check for <key>'s existence
config-key get <key>                     get <key>
config-key list                          list keys
config-key put <key> {<val>}             put <key>, value <val>

sage

Re: Consul

[Hunter Nield]

On Wed, Nov 5, 2014 at 4:38 PM, Loic Dachary <loic@dachary.org> wrote:
> I guess using radosgw with the S3/Swift API is close enough in terms of what Consul needs to store key/values. But maybe I don't understand what you mean by "easily accessible distributed KV store" and wrongly assume radosgw is easy enough ;-)

Yes, we did consider RGW. We were originally looking for something
simpler for internal use. More than librados but less than a full
object storage gateway. We didn't need Apache or multi-tenant
authentication, just somewhere to store keys and pull them out
elsewhere. Closer to clustered Memcache or Redis. Consul provides most
of that now and adds a few things like locks and long polling

>> On a side note, I haven't spoken to Dan in a while but curious on his
>> thoughts on the overlap on Consul in config management land. Service
>> discovery, remote execution, etc have some overlap in Puppet, Chef,
>> etc. Related to Ceph we're pondering it as alternative for deploying
>> mons/osds (larger scale ceph-deploy perhaps)
>
> Is there a framework for integration tests of some kind in Consul ? Although https://github.com/puppetlabs/beaker/ provides that for puppet, it is still rarely used and it is painful because even when used to develop a module, it is likely to break in unpredictable ways because module dependencies have no integration tests and suffer from frequent regressions. It would be great to see modern tools such as Consul encourage a more robust approach to integration tests with proper tooling from the start.

I'm not entirely sure about integration tests. Certainly there are
unit tests for the code but there doesn't seem to be much (that I can
see) about testing things like external health checks or remote exec.

Re: Consul

[John Spray]

Consul is an interesting thing.  It had crossed my mind as a service
monitoring/discovery thing for cases where:
 * We have services other than Ceph in the IO path (e.g. apache, samba, nfs)
 * The mons aren't happy (something to tell me which of my mons are up
even if there is no quorum)
 * There might be multiple Ceph clusters and you want one health state
reflecting both clusters

Most other monitoring tools (e.g. calamari) take the shortcut of
having a single central monitoring server -- something consul-esque
that is lighter-weight and more resilient could be a step forward for
cluster monitoring applications in more flexible and less enterprisey
environments.

The "whole separate service but it's lightweight so that's okay"
approach is embodied by Consul.  I think there is an alternative path
available that I think of as "we already have a consensus system,
let's make a way to plug monitoring applications on top of it" -- a
way to plug extra smarts into the mons could be interesting too.

John


On Wed, Nov 5, 2014 at 12:38 AM, Loic Dachary <loic@dachary.org> wrote:
> Hi Ceph,
>
> While at the OpenStack summit Dan Bode spoke highly of Consul ( https://consul.io/intro/index.html ). Its scope is new to me. Each individual feature is familiar but I'm not entirely sure if combining them into a single software is necessary. And I wonder how it could relate to Ceph. It is entirely possible that it does not even make sense to ask theses questions ;-)
>
> Cheers
>
> --
> Loïc Dachary, Artisan Logiciel Libre
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

consul

[sateesh m]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

Hi Guys,

I am trying to integrate consul package to my image.facing issue while fetching the sources.

WARNING: consul-git-r0 do_fetch: Failed to fetch URL git://github.com/hashicorp/consul.git, attempting MIRRORS if available
ERROR: consul-git-r0 do_fetch: Fetcher failure: Unable to find revision 944cc71026c007e7de9467ec3f38f0ad14464fcc in branch master even from upstream
ERROR: consul-git-r0 do_fetch: Fetcher failure for URL: 'git://github.com/hashicorp/consul.git'. Unable to fetch URL from any source.

Can anybody know please  tell  which revision ID i need to used to fix this issue. or any patch available suggest me.

Thanking you in advance.
--
Regards,
Sateesh

[-- Attachment #2: Type: text/html, Size: 844 bytes --]