aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorBharath <bharathb@research.att.com>2019-02-14 12:46:34 -0500
committerBharath <bharathb@research.att.com>2019-02-14 12:46:34 -0500
commit50bd365f7e30337a21806cd292e75c3f03985b79 (patch)
tree4ad360b36a585f05025af2d994a8aaed5e2d6ab7
parent4aad675a95e8106c65ac96846c3e573a11079ceb (diff)
Testing gerrit flow for Issue-ID: MUSIC-294
Change-Id: I1563ecc92214472333d457116a19b1beadfb2d52 Signed-off-by: Bharath <bharathb@research.att.com>
-rw-r--r--README.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/README.md b/README.md
index 3f83f2da..9d5c4cd1 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,6 @@
## MUSIC - Multi-site State Coordination Service
-To achieve 5 9s of availability on 3 9s or lower software and infrastructure in a cost-effective manner, ONAP components need to work in a reliable, active-active manner across multiple sites (platform-maturity resiliency level 3). A fundamental aspect of this is state management across geo-distributed sites in a reliable, scalable, highly available and efficient manner. This is an important and challenging problem because of three fundamental reasons:
+To truly achieve 5 9s of availability on 3 9s or lower software and infrastructure in a cost-effective manner, ONAP components need to work in a reliable, active-active manner across multiple sites (platform-maturity resiliency level 3). A fundamental aspect of this is state management across geo-distributed sites in a reliable, scalable, highly available and efficient manner. This is an important and challenging problem because of three fundamental reasons:
* Current solutions for state-management of ONAP components like MariaDB clustering, that work very effectively within a site, may not scale across geo-distributed sites (e.g., Beijing, Amsterdam and Irvine) or allow partitioned operation (thereby compromising availability). This is mainly because WAN latencies are much higher across sites and frequent network partitions can occur.