frontend: add FAQ

Author: gyuho

frontend/app/app.routing.ts

@@ -68,7 +68,7 @@ const appRoutes: Routes = [
                 children: [
                     { path: 'announcing-etcd-v31', component: AnnouncingEtcdV31Component },
                     { path: 'announcing-etcd-website', component: AnnouncingEtcdWebsiteComponent },
-                    { path: 'etcd-stm', component: STMComponent },
+                    { path: 'stm', component: STMComponent },
                 ],
             }
         ],

frontend/app/blog/2016/stm.component.html

@@ -40,8 +40,7 @@ <h2 class="blog-title">Serializability and Distributed Software Transactional Me
                 atomicity. To judge whether etcd3’s primitives are expressive and efficient, we implemented and benchmarked common distributed concurrency control "recipes".
             </p>
             <p>
-                This post looks at the atomicity granted by etcd3’s new mini-transactions. We’ll cover etcd3 transactions and demonstrate atomic updates with transactions. Next, we’ll show how etcd’s revision metadata naturally maps to software transactional memory (STM)
-                by outlining a simple client-side STM implementation. Finally, we’ll show this STM implementation is a performant alternative to distributed shared locks.
+                This post looks at the atomicity granted by etcd3’s new mini-transactions. We’ll cover etcd3 transactions and demonstrate atomic updates with transactions. Next, we’ll show how etcd’s revision metadata naturally maps to software transactional memory (STM)<sup>[1]</sup>                by outlining a simple client-side STM implementation. Finally, we’ll show this STM implementation is a performant alternative to distributed shared locks.
             </p>
 
             <br>
@@ -236,7 +235,11 @@ <h3>What’s Next?</h3>
                 in the v3 client <a href="https://github.com/coreos/etcd/tree/master/clientv3/concurrency" target="_blank" class="normal-link">concurrency package</a>.
             </p>
 
-
+            <br>
+            <hr align="left" class="footer-top-line">
+            <footer>
+                [1] "<a href="https://en.wikipedia.org/wiki/Software_transactional_memory" target="_blank" class="footer-link">Software transactional memory</a>," Wikipedia.
+            </footer>
         </article>
     </div>
 </md-sidenav-layout>

frontend/app/blog/blog.component.css

@@ -87,4 +87,28 @@ md-sidenav-layout {
     padding: 8px;
     margin: 1em 0px 1em;
     word-wrap: normal;
+}
+
+sup {
+    color: black;
+    font-family: 'Open Sans', sans-serif;
+    font-size: 10px;
+}
+
+footer {
+    color: black;
+    font-family: 'Open Sans', sans-serif;
+    font-size: 12px;
+}
+
+.footer-link {
+    color: dodgerblue;
+    text-decoration: none !important;
+    font-family: 'Open Sans', sans-serif;
+    font-size: 12px;
+}
+
+.footer-top-line {
+    color: darkgray;
+    width: 30%;
 }

frontend/app/blog/blog.component.html

@@ -18,6 +18,5 @@
 
     <div class="blog-group">
         <router-outlet></router-outlet>
-        Hello World! Welcome to etcd blogs!
     </div>
 </md-sidenav-layout>

frontend/app/blog/blog.component.ts

@@ -44,7 +44,7 @@ export class BlogComponent {
                     ),
                     new blogItem(
                         'Serializability and Distributed Software Transactional Memory with etcd3',
-                        '/blog/2016/etcd-stm'
+                        '/blog/2016/stm'
                     ),
                 ]
             ),

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

@@ -42,6 +42,13 @@ a {
     font-style: italic;
 }
 
+.code-link {
+    color: dodgerblue;
+    text-decoration: none !important;
+    font-family: 'Roboto', sans-serif;
+    font-size: 15px;
+}
+
 sup {
     color: black;
     font-family: 'Open Sans', sans-serif;
@@ -61,13 +68,6 @@ footer {
     font-size: 12px;
 }
 
-.code-link {
-    color: dodgerblue;
-    text-decoration: none !important;
-    font-family: 'Roboto', sans-serif;
-    font-size: 15px;
-}
-
 .footer-top-line {
     color: darkgray;
     width: 30%;

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

@@ -42,10 +42,15 @@ <h3 md-subheader>More</h3>
         <div id="cap-theorem-in-etcd"></div>
         <h2><a href="/doc/{{version.etcdVersionURL}}/faq#cap-theorem-in-etcd" class="faq-title">CAP theorem in etcd?</a></h2>
         <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.
+            CAP<sup>[1]</sup> 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>
+        <hr align="left" class="footer-top-line">
+        <footer>
+            [1] Seth Gilbert and Nancy Lynch: "<a href="https://pdfs.semanticscholar.org/24ce/ce61e2128780072bc58f90b8ba47f624bc27.pdf" target="_blank" class="footer-link">Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services</a>,"
+            ACM SIGACT News, volume 33, number 2, pages 51–59, 2002.
+        </footer>
+        <br><br>
 
         <div id="remove-member-first"></div>
         <h2><a href="/doc/{{version.etcdVersionURL}}/faq#remove-member-first" class="faq-title">Always remove first when replacing member?</a></h2>
@@ -56,17 +61,14 @@ <h2><a href="/doc/{{version.etcdVersionURL}}/faq#remove-member-first" class="faq
         <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.
@@ -76,7 +78,6 @@ <h2><a href="/doc/{{version.etcdVersionURL}}/faq#remove-member-first" class="faq
         </p>
         <br>
 
-
         <div id="why-so-strict-about-membership-change"></div>
         <h2><a href="/doc/{{version.etcdVersionURL}}/faq#why-so-strict-about-membership-change" class="faq-title">Why so strict about membershp change?</a></h2>
         <p>

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

@@ -36,15 +36,15 @@ <h2><a href="/doc/{{version.etcdVersionURL}}/why#why-etcd">Why etcd</a></h2>
                         <div class="feature">
                             <h3>Consistent</h3>
                             <p>
-                                etcd is not an eventually consistent database, where two different nodes give two different values. etcd provides <b>linearizability</b><sup>[2]</sup> with <b>strong consistency</b><sup>[3]</sup>. When write completes,
-                                all etcd clients read the same value, most recent and up-to-date in any node.
+                                etcd is not an eventually consistent database, where two different nodes can serve two different values (stale data). etcd provides <b>linearizability</b><sup>[2]</sup> with <b>strong consistency</b><sup>[3]</sup>. When
+                                write completes, all etcd clients would read the same, <i>most recent and up-to-date</i>, value in any node.
                             </p>
                         </div>
 
                         <div class="feature">
                             <h3>Partition Tolerant</h3>
                             <p>
-                                etcd continues to function, even with network partition, where message is not delivered or gets delayed. Network glitches are very common, and <b>no system is immune</b> from such network faults<sup>[4]</sup>.
+                                etcd continues to function, even with network partition, where message is not delivered or gets delayed. Network glitches are very common, and <b>no system is immune</b> from network faults<sup>[4]</sup>.
                             </p>
                         </div>