11:08:53 <Ysean> Should the _replicator database have 0 documents?
11:41:30 <Ysean> Innteresting... I am loading the audio prompt attachment from fauxton and couchdb is returning a 401 even though I specified the user.  I only mess with couchdb on a very limited basis.  Shouldn't I be able to download the wav attachment by calling it directly via curl while specifying the database admin credentials?
14:54:22 <Mooseable> Ysean: yes, it stores it as an attachment inside couchdb
14:55:33 <Mooseable> If you're getting 200 OK'd on one DB node, and 404 on another, there's something (possibly) wrong with your replication?
14:58:59 <Mooseable> To get the attachment via couch directly, you need to GET /db/doc/attachmentName. eg; /06/bb/{accountid}/{documentid}/vm-enter_new_pin.wav
15:01:23 <Mooseable> for system media, you need to make sure prompts are set up: sup kazoo_media_maintenance import_prompts /opt/kazoo/sounds/en/us/
15:02:34 <Mooseable> doc relating to system prompts: https://docs.2600hz.com/kazoo_dev/doc/internationalization/prompts/
16:38:20 <Ysean> Moosable, yup.. I did all that.
16:38:50 <Ysean> That's why I suspect a replication issue as well.  Can someone give me an example of what the _replication should look like?
16:43:06 <Ysean> er _replicator
16:56:56 <Ysean> well, that's interesting.  It seems I never actually configured the bigcouch nodes to cluster on this instance.
16:56:57 <Ysean> GAH
16:57:12 <Ysean> s/bigcouch/couchdb
17:18:33 <Ysean> Question... it slooks like the local.ini configs weren't updated for the cluster config... can I leave q=1 while setting r=2, w=2 and n=3 without negatively impacting the databases?
17:19:14 <Ysean> I have a feeling I'm going to be feeling some pain to make this right no matter what I do.
22:39:44 <Mooseable> q=1 should be fine
22:42:22 <Mooseable> Unless you suddenly need 12 nodes and you want to fragment the db across nodes for performance
22:43:23 <Mooseable> But you can always set up a new cluster and copy/replicate data into the new cluster