Code Review / music / mdbc.git / commit
? search:
summary | shortlog | log | commit | commitdiff | review | tree
(parent: 885a7be) | patch
Include version.properties 42/79942/1
authorTschaen, Brendan <ctschaen@att.com>
Thu, 7 Mar 2019 20:41:19 +0000 (15:41 -0500)
committerTschaen, Brendan <ctschaen@att.com>
Thu, 7 Mar 2019 20:41:19 +0000 (15:41 -0500)
commitc521acf91ac6c76bc83015102624ed141d69dbf0
treec2e74e60fdac7d48ac0f66e0cafd9610332416ddtree | snapshot
parent885a7bea8709bece6244990cbeba9b1cccc40ddccommit | diff
Include version.properties

Change-Id: I823d2f98ea215cd8f027c386ac459da31e0cf5ea
Issue-ID: MUSIC-359
Signed-off-by: Tschaen, Brendan <ctschaen@att.com>
version.properties [new file with mode: 0755] blob
The most crucial recipe is a multi-site database cache (mdbc) that enable ONAP components that maintain state in a SQL database to avail the benefits of MUSIC without compromising their need to use transactional SQL DBs. These ONAP components can rely on existing db clustering techniques like MariaDB for transactionality and complex querying within a site. mdbc will intercept each of these read/write calls to the db cluster and mirror this state to other geo-distributed sites through MUSIC either synchronously or asynchronously (configurable at a table-level). For example, components like the ONAP Service Orchestrator that use MariaDB to maintain state can directly use this recipe with no change to their SQL code.