Adding upstream version 1.16.0.upstream/1.16.0

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 20 insertions, 17 deletions

diff --git a/registry/README.md b/registry/README.md
index 5a9a2b3b..73890807 100644
--- a/registry/README.md
+++ b/registry/README.md
@@ -1,7 +1,11 @@
 # Registry
 
-Netdata registry implements the `my-netdata` menu on netdata dashboards.
-The `my-netdata` menu lists the netdata servers you have visited.
+The Netdata registry implements the node menu on the top left corner of the netdata dashboards and enables the Netdata cloud features, such as the node view.
+The node menu lists the netdata servers you have visited. The node view offers a lot of additional features on top of the menu, 
+[with many more to come](https://blog.netdata.cloud/posts/netdata-cloud-announcement/). 
+To enable the global Netdata registry and the cloud features, you need to Sign In to Netdata cloud. By signing in, you opt in to let the registry receive and store 
+the information described [here](#what-data-does-the-registry-store). 
+You can still get the node menu, but not the cloud features, if you [run your own registry](#run-your-own-registry).
 
 ## Why?
 
@@ -26,11 +30,13 @@ Using netdata, your monitoring infrastructure is embedded on each server, limiti
 
 However, the netdata approach introduces a few new issues that need to be addressed, one being **the list of netdata we have installed**, i.e. the URLs our netdata servers are listening.
 
-To solve this, netdata utilizes a **central registry**. This registry, together with certain browser features, allow netdata to provide unified cross-server dashboards. For example, when you jump from server to server using the `my-netdata` menu, several session settings (like the currently viewed charts, the current zoom and pan operations on the charts, etc.) are propagated to the new server, so that the new dashboard will come with exactly the same view.
+To solve this, netdata utilizes a **central registry**. This registry, together with certain browser features, allow netdata to provide unified cross-server dashboards. 
+For example, when you jump from server to server using the node menu, several session settings (like the currently viewed charts, the current zoom and pan operations on the charts, etc.) are propagated to the new server, so that the new dashboard will come with exactly the same view.
+Netdata cloud has a roadmap to [offer many more features](https://blog.netdata.cloud/posts/netdata-cloud-announcement/) over and above the simple node menu.
 
-## What is the registry?
+## What data does the registry store?
 
-The registry keeps track of 3 entities:
+The registry keeps track of 4 entities:
 
 1. **machines**: i.e. the netdata installations (a random GUID generated by each netdata the first time it starts; we call this **machine_guid**)
 
@@ -38,12 +44,17 @@ The registry keeps track of 3 entities:
 
 2. **persons**: i.e. the web browsers accessing the netdata installations (a random GUID generated by the registry the first time it sees a new web browser; we call this **person_guid**)
 
-  For each person, the registry keeps track of the netdata installations it has accessed and their URLs.
+  For each person, the registry keeps track of the netdata installations it has accessed and their URLs. 
 
 3. **URLs** of netdata installations (as seen by the web browsers)
 
   For each URL, the registry keeps the URL and nothing more. Each URL is linked to *persons* and *machines*. The only way to find a URL is to know its **machine_guid** or have a **person_guid** it is linked to it.
 
+4. **accounts**: i.e. the information used to sign-in via one of the available sign-in methods. Depending on the method, this may include an email, an email and a profile picture.
+
+For *persons*/*accounts* and *machines*, the registry keeps links to *URLs*, each link with 2 timestamps (first time seen, last time seen) and a counter (number of times it has been seen).
+*machines*, *persons* and timestamps are stored in the netdata registry regardless of whether you sign in or not. 
+
 ## Who talks to the registry?
 
 Your web browser **only**! If sending this information is against your policies, you can [run your own registry](#run-your-own-registry)
@@ -52,19 +63,11 @@ Your netdata servers do not talk to the registry. This is a UML diagram of its o
 
 ![registry](https://cloud.githubusercontent.com/assets/2662304/19448565/11a70632-94ab-11e6-9d80-f410b4acb797.png)
 
-## What data does the registry store?
-
-Its database contains:
-
-- **random person GUIDs** (generated by the registry as a browser cookie)
-- **random machine GUIDs** (generated by each netdata server on its first run), including the hostname of the server netdata is running (without the domain)
-- **URLs** (the base URL for accessing a netdata server, as seen by the web browser)
-
-For *persons* and *machines*, the registry keeps links to *URLs*, each link with 2 timestamps (first time seen, last time seen) and a counter (number of times it has been seen).
 
 ## Which is the default registry?
 
 `https://registry.my-netdata.io`, which is currently served by `https://london.my-netdata.io`. This registry listens to both HTTP and HTTPS requests but the default is HTTPS.
+`https://netdata.cloud` is the additional registry endpoint, that enables [the cloud features](https://blog.netdata.cloud/posts/netdata-cloud-announcement/). It only accepts HTTPS.
 
 ### Can this registry handle the global load of netdata installations?
 
@@ -98,14 +101,14 @@ Note that we have not enabled the registry on the other servers. Only one netdat
 
 This is it. You have your registry now.
 
-You may also want to give your server different names under the **my-netdata** menu (i.e. to have them sorted / grouped). You can change its registry name, by setting on each netdata server:
+You may also want to give your server different names under the node menu (i.e. to have them sorted / grouped). You can change its registry name, by setting on each netdata server:
 
 ```
 [registry]
     registry hostname = Group1 - Master DB
 ```
 
-So this server will appear in **my-netdata** as `Group1 - Master DB`. The max name length is 50 characters.
+So this server will appear in the node menu as `Group1 - Master DB`. The max name length is 50 characters.
 
 ### Limiting access to the registry