Merge pull request #22 from gyuho/faq

frontend: add initial '/faq' page

Author: gyuho

frontend/app/doc/tip/common.component.css

@@ -87,6 +87,20 @@ footer {
     font-size: 15px;
 }
 
+.faq-list {
+    color: dodgerblue;
+    text-decoration: none !important;
+    font-family: 'Open Sans', sans-serif;
+    font-size: 15px;
+}
+
+h2 .faq-title {
+    color: dodgerblue;
+    text-decoration: none !important;
+    font-family: 'Open Sans', sans-serif;
+    font-size: 20px;
+}
+
 .versions-link-main {
     color: black;
     text-decoration: none !important;
@@ -399,4 +413,48 @@ section {
     section {
         padding: 15px 0
     }
+}
+
+@media screen and (min-width: 768px) {
+    .block.half {
+        margin-top: 0
+    }
+}
+
+@media screen and (min-width: 768px) {
+    .block-copy.half {
+        float: left;
+        display: block;
+        margin-right: 4.34783%;
+        width: 47.82609%
+    }
+    .block-copy.half:last-child {
+        margin-right: 0
+    }
+}
+
+.block-copy p {
+    margin-top: 30px;
+    line-height: 1.75rem;
+    color: #000
+}
+
+@media screen and (min-width: 768px) {
+    section.more-about .inner {
+        display: table;
+        max-width: 1100px
+    }
+}
+
+@media screen and (min-width: 768px) {
+    section.more-about .inner .block-copy {
+        float: left;
+        display: block;
+        margin-right: 4.34783%;
+        width: 47.82609%;
+        padding-right: 35px
+    }
+    section.more-about .inner .block-copy:last-child {
+        margin-right: 0
+    }
 }

frontend/app/doc/tip/faq.component.html

@@ -19,6 +19,55 @@ <h3 md-subheader>More</h3>
 
     <div class="doc-group">
         <router-outlet></router-outlet>
-        <p>Sorry, this page is still working in progress.</p>
+
+        <div class="inner">
+            <div class="block block-copy half">
+                <a href="/doc/{{version.etcdVersionURL}}/faq#cap-theorem-in-etcd" class="faq-list">CAP theorem in etcd?</a>
+            </div>
+            <div class="block block-copy half">
+                <a href="/doc/{{version.etcdVersionURL}}/faq#remove-member-first" class="faq-list">Always remove first when replacing member?</a>
+            </div>
+        </div>
+
+        <br>
+        <hr>
+        <br>
+
+        <h2><a href="/doc/{{version.etcdVersionURL}}/faq#cap-theorem-in-etcd" class="faq-title">CAP theorem in etcd?</a></h2>
+        <div id="cap-theorem-in-etcd"></div>
+        <p>
+            CAP often represents <i>Consistency</i>, <i>Availability</i>, <i>Partition tolerance</i>: you can only pick 2 out of 3. Since network partition is not avoidable, you are left with either consitency or availability when partition happens. That
+            is, systems with A and P are more tolerant of network faults, but possible to serve stale data. etcd chooses C and P to achieve linearizability with strong consistency.
+        </p>
+        <br>
+
+        <h2><a href="/doc/{{version.etcdVersionURL}}/faq#remove-member-first" class="faq-title">Always remove first when replacing member?</a></h2>
+        <div id="remove-member-first"></div>
+        <p>
+            When replacing an etcd node, we recommend to remove the member first and then add its replacement. etcd employs distributed consensus based on a quorum model; (n+1)/2 members, a majority, must agree on a proposal before it can be committed to the cluster.
+            These proposals include key-value updates and membership changes. This model totally avoids any possibility of split brain inconsistency. The downside is permanent quorum loss is catastrophic.
+        </p>
+        <p>
+            How this applies to membership:
+        </p>
+
+        <p>
+            If a 3-member cluster has 1 downed member, it can still make forward progress because the quorum is 2 and 2 members are still live. However, adding a new member to a 3-member cluster will increase the quorum to 3 because 3 votes are required for a majority
+            of 4 members. Since the quorum increased, this extra member buys nothing in terms of fault tolerance; the cluster is still one node failure away from being unrecoverable.
+        </p>
+
+        <p>
+            Additionally, that new member is risky because it may turn out to be misconfigured or incapable of joining the cluster. In that case, there's no way to recover quorum because the cluster has two members down and two members up, but needs three votes to
+            change membership to undo the botched membership addition. etcd will by default (as of last week) reject member add attempts that could take down the cluster in this manner.
+        </p>
+
+        <p>
+            On the other hand, if the downed member is removed from cluster membership first, the number of members becomes 2 and the quorum remains at 2. Following that removal by adding a new member will also keep the quorum steady at 2. So, even if the new node
+            can't be brought up, it's still possible to remove the new member through quorum on the remaining live members.
+        </p>
+        <p>
+            Reference <a href="https://github.com/coreos/etcd/issues/6114" target="_blank" class="normal-link">https://github.com/coreos/etcd/issues/6114</a>
+        </p>
+        <br>
     </div>
 </md-sidenav-layout>

frontend/app/home/home.component.css

@@ -60,7 +60,7 @@ h2 {
 }
 
 .block+.block {
-    margin-top: 60px
+    margin-top: 50px
 }
 
 @media screen and (min-width: 768px) {
@@ -119,12 +119,6 @@ h2 {
     }
 }
 
-@media screen and (min-width: 768px) {
-    section.updates .inner {
-        max-width: 1040px
-    }
-}
-
 .aspect-ratio-16-9 {
     position: relative;
     width: 100%;