# Edelight MongoDB Cookbook
**URL:** https://discourse.chef.io/t/edelight-mongodb-cookbook/5837
**Category:** Chef Infra (archive)
**Created:** [October 22, 2014, 7:53pm UTC](https://discourse.chef.io/t/edelight-mongodb-cookbook/5837 "2014-10-22T19:53:52Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@Douglas\_Garstang](https://discourse.chef.io/u/Douglas_Garstang)
#### Post date: [October 22, 2014, 7:53pm UTC](https://discourse.chef.io/t/edelight-mongodb-cookbook/5837/1 "2014-10-22T19:53:52Z")
I'm wondering if anyone has actually gotten the Edelight MongoDB cookbook
to work, with multiple shards and multiple replicas per shard? I've been
playing with it for months now and I'm frustrated beyond belief. We had the
folks from mongodb come out and meet us a few months ago and they
anecdotally told us they had heard of people who were actually using it.
Since I'm so frustrated, and can't be bothered detailing all the issues
from scratch, here's part of an email I sent internally within our
organisation today about it...
"Last night, I was able to get the community cookbook to deploy two replica
sets, but I had to remove authentication to do so. I had issues getting the
sharding to work on the router, so, since the sharding is going to be
handled by mongos on the DBC rightscsale instances anyway, and Eugene has
said we _might_ not need sharding, I decided to go back to getting replica
sets with authentication to work.
When auth is enabled in the cookbook, it automatically tries to
authenticate every operation as the admin user when configuring
replication, which, if not previously configured will fail. This means the
admin user has to be created first. Since the cookbook puts the replset
option in the config file automatically on every node, the node knows it's
part of a replica set. This means the admin user can't be create on an
arbitrary node, but instead has to be created only the primary node.
However, there is no primary node until replication has been set up, which
it hasn't been yet because there is no admin user.
Someone suggested I work around this by spinning up a data node manually
(without the options configured by the cookbook to make it look like it's
part of a replica set) and then using the appropriate commands to create
the admin user. Not sure how I'd copy the database over to the instances.
In any case, that's hardly automated.
I asked why the admin user can't be added to the router. After all, that's
what it's for, right? Apparently db local users are propagated from the
router to the data nodes, but system level users (like the admin user) are
not. When I attempted to use the cookbook yesterday to create the admin
user on the router, mongo failed because the auth option isn't recognized
on the router. I don't know why. Maybe because system level users aren't
propagated. Even if I get the admin user created on the data nodes, this
will stop the admin user (presumably with the same credentials) from being
created on the router, and then sharding can't be configured on top of the
replica sets.
Once the keyfile option is supplied to the cookbook, then for reasons I
don't understand, the cookbook automatically adds the auth option to the
config file, which as we know, breaks the router. From what I've been told,
they are two different things. One is for internal authentication, and the
other is for external user authentication."
All very frustrating stuff. On top of that there's other issues, like the
fact that the shard name is passed to the addshard() command instead of the
replica set name:
>
>
> Best I can tell, multiple shards just can't work.
> shard\_nodes = search(
> :node,
> "mongodb\_cluster\_name:#{new\_resource.cluster\_name} AND
> mongodb\_is\_shard:true AND
> chef\_environment:#{node.chef\_environment}"
> )
> That's going to return ALL nodes across...
The replica set name used in the chef search has a hard coded "rs\_" at the
front, and this isn't documented anywhere which initially caused a lot of
time to be wasted:
[https://github.com/edelight/chef-mongodb/issues/347](https://github.com/edelight/chef-mongodb/issues/347)
Is there a better cookbook for mongo?
Doug.
---
### Author:  [@James](https://discourse.chef.io/u/James)
#### Post date: [October 22, 2014, 8:13pm UTC](https://discourse.chef.io/t/edelight-mongodb-cookbook/5837/2 "2014-10-22T20:13:13Z")
Doug,
It has been over a year since I last used that cookbook, but I would urge
you to ask yourself earnestly whether the complexity is necessary. Unless
you're hosting mongodb clusters for customers in an automated fashion, or
you require numerous different clusters for your application, the answer
may very well be no.
I had a lot of trouble with that cookbook; there were numerous bugs and the
original author was not responsive at the time (though that may have
changed). In the end, we wrote something simple that satisfied our needs,
which only handled installation and basic configuration steps. The advanced
configuration was done by hand, as automating it added significant risk
during issues you may encounter with a large mongodb cluster (however,
mongodb has improved significantly since I used it heavily, so stability
may be better).
There was not a better community option back then, though I'm not sure
about now. We later dropped mongodb entirely, replacing it with redis,
postgresql, and aerospike in different places and combinations.
Good luck! I would ask the 10gen guys to connect you to their customer who
has successfully used the cookbook, if you do continue on.
James
On Wed, Oct 22, 2014 at 12:53 PM, Douglas Garstang [doug.garstang@gmail.com](mailto:doug.garstang@gmail.com)
wrote:
> I'm wondering if anyone has actually gotten the Edelight MongoDB cookbook
> to work, with multiple shards and multiple replicas per shard? I've been
> playing with it for months now and I'm frustrated beyond belief. We had the
> folks from mongodb come out and meet us a few months ago and they
> anecdotally told us they had heard of people who were actually using it.
>
> Since I'm so frustrated, and can't be bothered detailing all the issues
> from scratch, here's part of an email I sent internally within our
> organisation today about it...
>
> "Last night, I was able to get the community cookbook to deploy two
> replica sets, but I had to remove authentication to do so. I had issues
> getting the sharding to work on the router, so, since the sharding is going
> to be handled by mongos on the DBC rightscsale instances anyway, and Eugene
> has said we _might_ not need sharding, I decided to go back to getting
> replica sets with authentication to work.
>
> When auth is enabled in the cookbook, it automatically tries to
> authenticate every operation as the admin user when configuring
> replication, which, if not previously configured will fail. This means the
> admin user has to be created first. Since the cookbook puts the replset
> option in the config file automatically on every node, the node knows it's
> part of a replica set. This means the admin user can't be create on an
> arbitrary node, but instead has to be created only the primary node.
> However, there is no primary node until replication has been set up, which
> it hasn't been yet because there is no admin user.
>
> Someone suggested I work around this by spinning up a data node manually
> (without the options configured by the cookbook to make it look like it's
> part of a replica set) and then using the appropriate commands to create
> the admin user. Not sure how I'd copy the database over to the instances.
> In any case, that's hardly automated.
>
> I asked why the admin user can't be added to the router. After all, that's
> what it's for, right? Apparently db local users are propagated from the
> router to the data nodes, but system level users (like the admin user) are
> not. When I attempted to use the cookbook yesterday to create the admin
> user on the router, mongo failed because the auth option isn't recognized
> on the router. I don't know why. Maybe because system level users aren't
> propagated. Even if I get the admin user created on the data nodes, this
> will stop the admin user (presumably with the same credentials) from being
> created on the router, and then sharding can't be configured on top of the
> replica sets.
>
> Once the keyfile option is supplied to the cookbook, then for reasons I
> don't understand, the cookbook automatically adds the auth option to the
> config file, which as we know, breaks the router. From what I've been told,
> they are two different things. One is for internal authentication, and the
> other is for external user authentication."
>
> All very frustrating stuff. On top of that there's other issues, like the
> fact that the shard name is passed to the addshard() command instead of the
> replica set name:
> [Sharding doesn't work. · Issue #348 · edelight/chef-mongodb · GitHub](https://github.com/edelight/chef-mongodb/issues/348)
>
> The replica set name used in the chef search has a hard coded "rs\_" at the
> front, and this isn't documented anywhere which initially caused a lot of
> time to be wasted:
> [RS\_ prefix hard coded. · Issue #347 · edelight/chef-mongodb · GitHub](https://github.com/edelight/chef-mongodb/issues/347)
>
> Is there a better cookbook for mongo?
>
> Doug.