Hi all,

as we raised at our last Arch meeting, the devops team is planning to
use CouchDB 2 instead CouchDB 1 for the backend of GPII cloud. The
main reason for moving to this version is that CouchDB 2 has good
scalability and high availability features[1] than the previous
version doesn't have.

>From the point of view of a client, the API of CouchDB 2 is 99%
compatible with the API of CouchDB 1.X [2], so GPII wouldn't need any
change in the code to work with. Also the entire cluster behaves like
a single CouchDB instance, being the clustering transparent for the
applications that use it.

All the data that is on the JSONs files of "TestData" directory can be
loaded without problems, and also the command:

GPII_FLOWMANAGER_PREFERENCES_URL=http://localhost:9081/preferences/%userToken
 npm run test:production

works fine on a complete stack of couchdb <-> preferences server <-> flowmanager

If someone wants to give a try, it can be installed either following
the installation guide[3] or using our Docker container:

Start the server:
   docker run -d --name couchdb -p 5984:5984 -p 5986:5986 gpii/couchdb

Destroy the server (all all the data):
   docker rm -f couchdb

CouchdDB 2 will listen to localhost ports 5984, and 5986 for admin
operations like the new Fauxton interface[4].

So being said the above, is there any concern of using this version on
the GPII cloud?

Tony raised an issue about the integration with Lucene[5], but it
seems that is not applicable to the components of GPII deployed at the
cloud.

Cheers,

[1] http://docs.couchdb.org/en/2.1.0/cluster/
[2] https://blog.couchdb.org/2016/09/20/2-0/
[3] http://docs.couchdb.org/en/2.1.0/install/
[4] http://localhost:5986/_utils/
[5] https://issues.gpii.net/browse/GPII-2637

-- 
Alfredo
_______________________________________________
Architecture mailing list
[email protected]
https://lists.gpii.net/mailman/listinfo/architecture

Reply via email to