Merge commit '868f19ad679743c4b31be5a8f51797379db5f46f' into josecv/t…

…el-2.4.3

concepts/intercepts.md

@@ -107,18 +107,21 @@ with all your dev tools.
 
 ## Personal intercept
 
+**Personal intercepts** allow you to be selective and intercept only
+some of the traffic to a service while not interfering with the rest
+of the traffic. This allows you to share a cluster with others on your
+team without interfering with their work.
+
 <Paper style="padding: 1em">
 <Animation class="mode-personal" />
 
-**Personal intercepts** allow you to be selective and intercept only
-some of the traffic to a service.
-
-**<span style="color: #f24e1e">Orange</span>** requests are being made
-by a developer on their laptop and the **<span style="color:
-#00c05b">green</span>** are made by a teammate on a different laptop.
+In the illustration above, **<span style="color: #f24e1e">Orange</span>**
+requests are being made by Developer 2 on their laptop and the
+**<span style="color: #00c05b">green</span>** are made by a teammate,
+Developer 1, on a different laptop.
 
-They can intercept the same service in the Kubernetes cluster to
-create a shared development environment.
+Each developer can intercept the Orders service for their requests only,
+while sharing the rest of the development environment.
 
 </Paper>
 

reference/config.md

@@ -78,7 +78,7 @@ Values for `images` are strings. These values affect the objects that are deploy
 so it's important to ensure users have the same configuration.
 
 Additionally, you can deploy the server-side components with [Helm](../../install/helm), to prevent them
-from being overridden by a client's config and use the [mutating-webhook](../clusterpconfig/#mutating-webhook)
+from being overridden by a client's config and use the [mutating-webhook](../cluster-config/#mutating-webhook)
 to handle installation of the `traffic-agents`.
 
 These are the valid fields for the `images` key:

reference/environment.md

@@ -26,3 +26,21 @@ There are three options available to do this:
   `telepresence intercept [service] --port [port] -- /bin/bash`
 
   This would start the intercept then launch the subshell on your laptop with all the same variables set as on the pod.
+
+## Telepresence Environment Variables
+
+Telepresence adds some useful environment variables in addition to the ones imported from the intercepted pod:
+
+### TELEPRESENCE_ROOT
+Directory where all remote volumes mounts are rooted. See [Volume Mounts](../volume/) for more info.
+
+### TELEPRESENCE_MOUNTS
+Colon separated list of remotely mounted directories.
+
+### TELEPRESENCE_CONTAINER
+The name of the intercepted container. Useful when a pod has several containers, and you want to know which one that was intercepted by Telepresence.
+
+### TELEPRESENCE_INTERCEPT_ID
+ID of the intercept (same as the "x-intercept-id" http header).
+
+Useful if you need special behavior when intercepting a pod. One example might be when dealing with pub/sub systems like Kafka, where all processes that don't have the `TELEPRESENCE_INTERCEPT_ID` set can filter out all messages that contain an `x-intercept-id` header, while those that do, instead filter based on a matching `x-intercept-id` header. This is to assure that messages belonging to a certain intercept always are consumed by the intercepting process.

reference/volume.md

@@ -29,7 +29,7 @@ bash-3.2$ echo $TELEPRESENCE_ROOT
 
 <Alert severity="info"><code>--mount=true</code> is the default if a <code>mount</code> option is not specified, use <code>--mount=false</code> to disable mounting volumes.</Alert>
 
-With either method, the code you run locally either from the subshell or from the intercept command will need to be prepended with the `$TELEPRESENCE_ROOT` environment variable to utilitze the mounted volumes.
+With either method, the code you run locally either from the subshell or from the intercept command will need to be prepended with the `$TELEPRESENCE_ROOT` environment variable to utilize the mounted volumes.
 
 For example, Kubernetes mounts secrets to `/var/run/secrets/kubernetes.io` (even if no `mountPoint` for it exists in the Pod spec).  Once mounted, to access these you would need to change your code to use `$TELEPRESENCE_ROOT/var/run/secrets/kubernetes.io`.
 

releaseNotes.yml

@@ -38,6 +38,92 @@ docDescription: >-
 changelog: https://github.com/telepresenceio/telepresence/blob/$branch$/CHANGELOG.md
 
 items:
+
+  - version: 2.4.3
+    date: '2021-09-14'
+    notes:
+      - type: feature
+        title: Environment variable TELEPRESENCE_INTERCEPT_ID available in interceptor's environment
+        body: >-
+          When you perform an intercept, we now include a <code>TELEPRESENCE_INTERCEPT_ID</code> environment
+          variable in the environment.
+        docs: reference/environment/#telepresence-environment-variables
+
+      - type: bugfix
+        title: Improved daemon stability
+        body: >-
+          Fixed a timing bug that sometimes caused a "daemon did not start" failure.
+
+      - type: bugfix
+        title: Complete logs for Windows
+        body: >-
+          Crash stack traces and other errors were incorrectly not written to log files. This has
+          been fixed so logs for Windows should be at parity with the ones in MacOS and Linux.
+
+      - type: bugfix
+        title: Log rotation fix for Linux kernel 4.11+
+        body: >-
+          On Linux kernel 4.11 and above, the log file rotation now properly reads the
+          <code>birth-time</code> of the log file. Older kernels continue to use the old behavior
+          of using the <code>change-time</code> in place of the <code>birth-time</code>.
+
+      - type: bugfix
+        title: Improved error messaging
+        body: >-
+          When Telepresence encounters an error, it tells the user where they should look for
+          logs related to the error. We have refined this so that it only tells users to look
+          for errors in the daemon logs for issues that are logged there.
+
+      - type: bugfix
+        title: Stop resolving localhost
+        body: >-
+          When using the overriding DNS resolver, it will no longer apply search paths when
+          resolving <code>localhost</code>, since that should be resolved on the user's machine
+          instead of the cluster.
+        docs: reference/routing#linux-systemd-resolved-resolver
+
+      - type: bugfix
+        title: Variable cluster domain
+        body: >-
+          Previously, the cluster domain was hardcoded to <code>cluster.local</code>.  While this
+          is true for many kubernetes clusters, it is not for all of them. Now this value is
+          retrieved from the <code>traffic-manager</code>.
+
+      - type: bugfix
+        title: Improved cleanup of traffic-agents
+        body: >-
+          Telepresence now uninstalls <code>traffic-agents</code> installed via mutating webhook
+          when using <code>telepresence uninstall --everything</code>.
+
+      - type: bugfix
+        title: More large file transfer fixes
+        body: >-
+          Downloading large files during an intercept will no longer cause timeouts and hanging
+          <code>traffic-agents</code>.
+
+      - type: bugfix
+        title: Setting --mount to false when intercepting works as expected
+        body: >-
+          When using <code>--mount=false</code> while performing an intercept, the file system
+          was still mounted.  This has been remedied so the intercept behavior respects the
+          flag.
+        docs: reference/volume
+
+      - type: bugfix
+        title: Traffic-manager establishes outbound connections in parallel
+        body: >-
+          Previously, the <code>traffic-manager</code> established outbound connections
+          sequentially. This resulted in slow (and failing) <code>Dial</code> calls would
+          block all outbound traffic from the workstation (for up to 30 seconds). We now
+          establish these connections in parallel so that won't occur.
+        docs: reference/routing/#outbound
+
+      - type: bugfix
+        title: Status command reports correct DNS settings
+        body: >-
+          <code>Telepresence status</code> now correctly reports DNS settings for all operating
+          systems, instead of <code>Local IP:nil, Remote IP:nil</code> when they don't exist.
+
   - version: 2.4.2
     date: '2021-09-01'
     notes: