-
-
Notifications
You must be signed in to change notification settings - Fork 524
/
CHANGELOG.yml
1177 lines (1150 loc) · 73.7 KB
/
CHANGELOG.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
# The YAML in this file should contain:
#
# items: An array of releases with the following attributes:
# - version: The (optional) version number of the release, if applicable.
# - date: >-
# The date of the release in the format YYYY-MM-DD.
# If the date is (SUPERSEDED), then the release didn't happen, which means
# that its notes belong to the next release.
# - notes: An array of noteworthy changes included in the release, each having the following attributes:
# - type: The type of change, one of `bugfix`, `feature`, `security` or `change`.
# - title: A short title of the noteworthy change.
# - body: >-
# Two or three sentences describing the change and why it
# is noteworthy. This is HTML, not plain text or
# markdown. It is handy to use YAML's ">-" feature to
# allow line-wrapping.
# - image: >-
# The URL of an image that visually represents the
# noteworthy change. This path is relative to the
# `release-notes` directory; if this file is
# `FOO/releaseNotes.yml`, then the image paths are
# relative to `FOO/release-notes/`.
# - docs: The path to the documentation page where additional information can be found.
#
# For older changes, see CHANGELOG.OLD.md
items:
- version: 2.22.0
date: (TBD)
notes:
- type: feature
title: Unify how Traffic Manager selects namespaces
body: |-
The definition of what namespaces that a Traffic Manager would manage use was scattered into several Helm
chart values, such as `manager.Rbac.namespaces`, `client.Rbac.namespaces`, and
`agentInjector.webhook.namespaceSelector`. The definition is now unified to the mutual exclusive top-level
Helm chart values `namespaces` and `namespaceSelector`.
The `namespaces` value is just for convenience and a short form of expressing:
```yaml
namespaceSelector:
matchExpressions:
- key: kubernetes.io/metadata.name
operator: in
values: <namespaces>`.
```
docs: install/manager#static-versus-dynamic-namespace-selection
- type: change
title: Drop deprecated current-cluster-id command.
body: >-
The clusterID was deprecated some time ago, and replaced by the ID of the namespace where the traffic-manager
is installed.
- type: bugfix
title: Conflict detection between namespaced and cluster-wide install.
body: >-
The namespace conflict detection mechanism would only discover conflicts between two _namespaced_ Traffic
Managers trying to manage the same namespace. This is now fixed so that all types conflicts are discovered.
docs: install/manager#namespace-collision-detection
- type: bugfix
title: Don't dispatch DNS discovery queries to the cluster.
body: >-
macOS based systems will often PTR queries using nameslike `b._dns-sd._udp`, lb._dns-sd._udp, or
`db-dns-sd._udp`. Those queries are no longer dispatched to the cluster.
- version: 2.21.1
date: 2024-12-17
notes:
- type: bugfix
title: Allow ingest of serverless deployments without specifying an inject-container-ports annotation
body: >-
The ability to intercept a workload without a service is built around the
`telepresence.getambassador.io/inject-container-ports` annotation, and it was also required in order to ingest
such a workload. This was counterintuitive and the requirement was removed. An ingest doesn't use a port.
docs: https://github.com/telepresenceio/telepresence/issues/3741
- type: bugfix
title: Upgrade module dependencies to get rid of critical vulnerability.
body: >-
Upgrade module dependencies to latest available stable. This includes upgrading golang.org/x/crypto, which
had critical issues, from 0.30.0 to 0.31.0 where those issues are resolved.
- version: 2.21.0
date: 2024-12-13
notes:
- type: feature
title: Automatic VPN conflict avoidance
body: >-
Telepresence not only detects subnet conflicts between the cluster and workstation VPNs but also resolves them
by performing network address translation to move conflicting subnets out of the way.
docs: reference/vpn
- type: feature
title: Virtual Address Translation (VNAT).
body: >-
It is now possible to use a virtual subnet without routing the affected IPs to a specific workload. A new
`telepresence connect --vnat CIDR` flag was added that will perform virtual network address translation of
cluster IPs. This flag is very similar to the `--proxy-via CIDR=WORKLOAD` introduced in 2.19, but without
the need to specify a workload.
docs: reference/vpn
- type: feature
title: Intercepts targeting a specific container
body: |-
In certain scenarios, the container owning the intercepted port differs
from the container the intercept targets. This port owner's sole purpose
is to route traffic from the service to the intended container, often
using a direct localhost connection.
This update introduces a `--container <name>` option to the intercept
command. While this option doesn't influence the port selection, it
guarantees that the environment variables and mounts propagated to the
client originate from the specified container. Additionally, if the
`--replace` option is used, it ensures that this container is replaced.
docs: reference/intercepts/container
- type: feature
title: New telepresence ingest command
body: >-
The new `telepresence ingest` command, similar to `telepresence intercept`, provides local access to the
volume mounts and environment variables of a targeted container. However, unlike `telepresence intercept`,
`telepresence ingest` does not redirect traffic to the container and ensures that the mounted volumes are
read-only.
An ingest requires a traffic-agent to be installed in the pods of the targeted workload. Beyond that, it's
a client-side operation. This allows developers to have multiple simultaneous ingests on the same container.
docs: howtos/intercepts#ingest-your-service
- type: feature
title: New telepresence curl command
body: >-
The new `telepresence curl` command runs curl from within a container. The command requires that a connection
has been established using `telepresence connect --docker`, and the container that runs `curl` will share the
same network as the containerized telepresence daemon.
docs: reference/docker-run#the-telepresence-curl-command
- type: feature
title: New telepresence docker-run command
body: >-
The new `telepresence docker-run <flags and arguments>` requires that a connection has been established using
`telepresence connect --docker` It will perform a `docker run <flags and arguments>` and add the flag necessary
to ensure that started container shares the same network as the containerized telepresence daemon.
docs: reference/docker-run#the-telepresence-docker-run-command
- type: feature
title: Mount everything read-only during intercept
body: >-
It is now possible to append ":ro" to the intercept `--mount` flag value. This ensures that all remote volumes
that the intercept mounts are read-only.
- type: feature
title: Unify client configuration
body: >-
Previously, client configuration was divided between the config.yml file and a Kubernetes extension. DNS and
routing settings were initially found only in the extension. However, the Helm client structure allowed
entries from both.
To simplify this, we've now aligned the config.yml and Kubernetes extension with the Helm client structure.
This means DNS and routing settings are now included in both. The Kubernetes extension takes precedence over
the config.yml and Helm client object.
While the old-style Kubernetes extension is still supported for compatibility, it cannot be used with the new
style.
docs: reference/config
- type: feature
title: Use WebSockets for port-forward instead of the now deprecated SPDY.
body: >-
Telepresence will now use WebSockets instead of SPDY when creating port-forwards to the Kubernetes Cluster, and
will fall back to SPDY when connecting to clusters that don't support SPDY. Use of the deprecated SPDY can be
forced by setting `cluster.forceSPDY=true` in the `config.yml`.
See [Streaming Transitions from SPDY to WebSockets](https://kubernetes.io/blog/2024/08/20/websockets-transition/)
for more information about this transition.
- type: feature
title: Make usage data collection configurable using an extension point, and default to no-ops
body: >-
The OSS code-base will no longer report usage data to the proprietary collector at Ambassador Labs. The actual calls
to the collector remain, but will be no-ops unless a proper collector client is installed using an extension point.
- type: feature
title: Add deployments, statefulSets, replicaSets to workloads Helm chart value
body: >-
The Helm chart value `workloads` now supports the kinds `deployments.enabled`, `statefulSets.enabled`, `replicaSets.enabled`.
and `rollouts.enabled`. All except `rollouts` are enabled by default. The traffic-manager will ignore workloads, and
Telepresence will not be able to intercept them, if the `enabled` of the corresponding kind is set to `false`.
docs: reference/intercepts/sidecar#disable-workloads
- type: feature
title: Improved command auto-completion
body: >-
The auto-completion of namespaces, services, and containers have been added where appropriate, and the default
file auto completion has been removed from most commands.
- type: feature
title: Docker run flags --publish, --expose, and --network now work with docker mode connections
body: >-
After establishing a connection to a cluster using `telepresence connect --docker`, you can run new containers that share
the same network as the containerized daemon that maintains the connection. This enables seamless communication between
your local development environment and the remote services.
Normally, Docker has a limitation that prevents combining a shared network configuration with custom networks
and exposing ports. However, Telepresence now elegantly circumvents this limitation so that a container started with
`telepresence docker-run`, `telepresence intercept --docker-run`, or `telepresence ingest --docker-run` can use flags
like `--network`, `--publish`, or `--expose`.
To achieve this, Telepresence temporarily adds the necessary network to the containerized daemon. This allows the new
container to join the same network. Additionally, Telepresence starts extra socat containers to handle port mapping,
ensuring that the desired ports are exposed to the local environment.
docs: reference/docker-run#the-telepresence-docker-run-command
- type: feature
title: Prevent recursion in the Telepresence Virtual Network Interface (VIF)
body: >-
Network problems may arise when running Kubernetes locally (e.g., Docker Desktop, Kind, Minikube, k3s),
because the VIF on the host is also accessible from the cluster's nodes. A request that isn't handled by a
cluster resource might be routed back into the VIF and cause a recursion.
These recursions can now be prevented by setting the client configuration property
`routing.recursionBlockDuration` so that new connection attempts are temporarily blocked for a specific
IP:PORT pair immediately after an initial attempt, thereby effectively ending the recursion.
docs: howtos/cluster-in-vm
- type: feature
title: Allow Helm chart to be included as a sub-chart
body: >-
The Helm chart previously had the unnecessary restriction that the .Release.Name under which telepresence is installed is literally
called "traffic-manager". This restriction was preventing telepresence from being included as a sub-chart in a parent chart
called anything but "traffic-manager". This restriction has been lifted.
- type: feature
title: Add Windows arm64 client build
body: >-
Telepresence client is now available for Windows ARM64.
Updated the release workflow files in github actions to build and publish the Windows ARM64 client.
- type: change
title: The --agents flag to telepresence uninstall is now the default.
body: >-
The `telepresence uninstall` was once capable of uninstalling the traffic-manager as well as traffic-agents.
This behavior has been deprecated for some time now and in this release, the command is all about uninstalling
the agents. Therefore the `--agents` flag was made redundant and whatever arguments that are given to the
command must be name of workloads that have an agent installed unless the `--all-agents` is used, in which
case no arguments are allowed.
- type: change
title: Performance improvement for the telepresence list command
body: >-
The `telepresence list` command will now retrieve its data from the traffic-manager, which significantly
improves its performance when used on namespaces that have a lot of workloads.
- type: change
title: During an intercept, the local port defaults to the targeted port of the intercepted container instead of 8080.
body: >-
Telepresence mimics the environment of a target container during an intercept, so it's only natural that the default
for the local port is determined by the targeted container port rather than just defaulting to 8080.
A default can still be explicitly defined using the `config.intercept.defaultPort` setting.
- type: change
title: Move the telepresence-intercept-env configmap data into traffic-manager configmap.
body: >-
There's no need for two configmaps that store configuration data for the traffic manager. The traffic-manager
configmap is also watched, so consolidating the configuration there saves some k8s API calls.
- type: change
title: Tracing was removed.
body: >-
The ability to collect trace has been removed along with the `telepresence gather-traces` and
`telepresence upload-traces` commands. The underlying code was complex and has not been well maintained since
its inception in 2022. We have received no feedback on it and seen no indication that it has ever been used.
- type: bugfix
title: Remove obsolete code checking the Docker Bridge for DNS
body: >-
The DNS resolver checked the Docker bridge for messages on Linux. This code was obsolete and caused problems
when running in Codespaces.
- type: bugfix
title: Fix telepresence connect confusion caused by /.dockerenv file
body: >-
A `/.dockerenv` will be present when running in a GitHub Codespaces environment. That doesn't mean that
telepresence cannot use docker, or that the root daemon shouldn't start.
- type: bugfix
title: Cap timeouts.connectivityCheck at 5 seconds.
body: >-
The timeout value of `timeouts.connectivityCheck` is used when checking if a cluster is already reachable
without Telepresence setting up an additional network route. If it is, this timeout should be high enough to
cover the delay when establishing a connection. If this delay is higher than a second, then chances are very
low that the cluster already is reachable, and if it can, that all accesses to it will be very slow. In such
cases, Telepresence will create its own network interface and do perform its own tunneling.
The default timeout for the check remains at 500 millisecond, which is more than sufficient for the majority
of cases.
- type: bugfix
title: Prevent that traffic-manager injects a traffic-agent into itself.
body: >-
The traffic-manager can never be a subject for an intercept, ingest, or proxy-via, because that means that
it injects the traffic-agent into itself, and it is not designed to do that. A user attempting this will
now see a meaningful error message.
- type: bugfix
title: Don't include pods in the kube-system namespace when computing pod-subnets from pod IPs
body: >-
A user would normally never access pods in the `kube-system` namespace directly, and automatically including pods
included there when computing the subnets will often lead to problems when running the cluster locally. This namespace
is therefore now excluded in situations when the pod subnets are computed from the IPs of pods. Services in this
namespace will still be available through the service subnet.
If a user should require the pod-subnet to be mapped, it can be added to the `client.routing.alsoProxy`
list in the helm chart.
- type: bugfix
title: Let routes belonging to an allowed conflict be added as a static route on Linux.
body: >-
The `allowConflicting` setting didn't always work on Linux because the conflicting subnet was just added as a
link to the TUN device, and therefore didn't get subjected to routing rule used to assign priority to the
given subnet.
- version: 2.20.3
date: 2024-11-18
notes:
- type: bugfix
title: Ensure that Telepresence works with GitHub Codespaces
body: >-
GitHub Codespaces runs in a container, but not as root. Telepresence didn't handle this situation
correctly and only started the user daemon. The root daemon was never started.
docs: https://github.com/telepresenceio/telepresence/issues/3722
- type: bugfix
title: Mounts not working correctly when connected with --proxy-via
body: >-
A mount would try to connect to the sftp/ftp server using the original (cluster side) IP although that
IP was translated into a virtual IP when using `--proxy-via`.
docs: https://github.com/telepresenceio/telepresence/issues/3715
- version: 2.20.2
date: 2024-10-21
notes:
- type: bugfix
title: Crash in traffic-manager configured with agentInjector.enabled=false
body: >-
A traffic-manager that was installed with the Helm value `agentInjector.enabled=false` crashed when a
client used the commands `telepresence version` or `telepresence status`. Those commands would call
a method on the traffic-manager that panicked if no traffic-agent was present. This method will now
instead return the standard `Unavailable` error code, which is expected by the caller.
- version: 2.20.1
date: 2024-10-10
notes:
- type: bugfix
title: Some workloads missing in the telepresence list output (typically replicasets owned by rollouts).
body: >-
Version 2.20.0 introduced a regression in the `telepresence list` command, resulting in the omission of
all workloads that were owned by another workload. The correct behavior is to just omit those workloads
that are owned by the supported workload kinds `Deployment`, `ReplicaSet`, `StatefulSet`, and `Rollout`.
Furthermore, the `Rollout` kind must only be considered supported when the Argo Rollouts feature is
enabled in the traffic-manager.
- type: bugfix
title: Allow comma separated list of daemons for the gather-logs command.
body: >-
The name of the `telepresence gather-logs` flag `--daemons` suggests that the argument can contain more
than one daemon, but prior to this fix, it couldn't. It is now possible to use a comma separated
list, e.g. `telepresence gather-logs --daemons root,user`.
- version: 2.20.0
date: 2024-10-03
notes:
- type: feature
title: Add timestamp to telepresence_logs.zip filename.
body: >-
Telepresence is now capable of easily find telepresence gather-logs by certain timestamp.
- type: feature
title: Enable intercepts of workloads that have no service.
body: >-
Telepresence is now capable of intercepting workloads that have no associated service. The intercept will then target container port
instead of a service port. The new behavior is enabled by adding a <code>telepresence.getambassador.io/inject-container-ports</code>
annotation where the value is a comma separated list of port identifiers consisting of either the name or the port number of a container
port, optionally suffixed with `/TCP` or `/UDP`.
docs: https://telepresence.io/docs/reference/intercepts/cli#intercepting-without-a-service
- type: feature
title: Publish the OSS version of the telepresence Helm chart
body: >-
The OSS version of the telepresence helm chart is now available at ghcr.io/telepresenceio/telepresence-oss, and
can be installed using the command:<br/>
<code>helm install traffic-manager oci://ghcr.io/telepresenceio/telepresence-oss --namespace ambassador --version 2.20.0</code>
The chart documentation is published at <a href="https://artifacthub.io/packages/helm/telepresence-oss/telepresence-oss">ArtifactHUB</a>.
docs: https://artifacthub.io/packages/helm/telepresence-oss/telepresence-oss
- type: feature
title: Control the syntax of the environment file created with the intercept flag --env-file
body: >-
A new <code>--env-syntax <syntax></code> was introduced to allow control over the syntax of the file created when using the intercept
flag <code>--env-file <file></code>. Valid syntaxes are "docker", "compose", "sh", "csh", "cmd",
and "ps"; where "sh", "csh", and "ps" can be suffixed with ":export".
docs: https://telepresence.io/docs/reference/environment
- type: feature
title: Add support for Argo Rollout workloads.
body: >-
Telepresence now has an opt-in support for Argo Rollout workloads.
The behavior is controlled by `workloads.argoRollouts.enabled` Helm chart value.
It is recommended to set the following annotation <code>telepresence.getambassador.io/inject-traffic-agent: enabled</code>
to avoid creation of unwanted revisions.
- type: bugfix
title: Enable intercepts of containers that bind to podIP
body: >-
In previous versions, the traffic-agent would route traffic to localhost during periods when an intercept wasn't
active. This made it impossible for an application to bind to the pod's IP, and it also meant that service meshes binding
to the podIP would get bypassed, both during and after an intercept had been made.
This is now changed, so that the traffic-agent instead forwards non intercepted requests to the pod's IP, thereby
enabling the application to either bind to localhost or to that IP.
- type: change
title: Use ghcr.io/telepresenceio instead of docker.io/datawire for OSS images and the telemount Docker volume plugin.
body: >-
All OSS telepresence images and the telemount Docker plugin are now published at the public registry ghcr.io/telepresenceio
and all references from the client and traffic-manager has been updated to use this registry
instead of the one at docker.io/datawire.
- title: Use nftables instead of iptables-legacy
type: change
body: >-
Some time ago, we introduced iptables-legacy because users had problems using Telepresence with Fly.io where nftables
wasn't supported by the kernel. Fly.io has since fixed this, so Telepresence will now use nftables again. This in turn,
ensures that modern systems that lack support iptables-legacy will work.
- type: bugfix
title: Root daemon wouldn't start when sudo timeout was zero.
body: >-
The root daemon refused to start when <code>sudo</code> was configured with a <code>timestamp_timeout=0</code>.
This was due to logic that first requested root privileges using a sudo call, and then relied on that these
privileges were cached, so that a subsequent call using <code>--non-interactive</code> was guaranteed to succeed.
This logic will now instead do one single sudo call, and rely solely on sudo to print an informative prompt and
start the daemon in the background.
- type: bugfix
title: Detect minikube network when connecting with --docker
body: >-
A <code>telepresence connect --docker</code> failed when attempting to connect to a minikube that
uses a docker driver because the containerized daemon did not have access to the <code>minikube</code>
docker network. Telepresence will now detect an attempt to connect to that network and attach it to
the daemon container as needed.
- version: 2.19.1
date: "2024-07-12"
notes:
- type: feature
title: Add brew support for the OSS version of Telepresence.
body: >-
The Open-Source Software version of Telepresence can now be installed using the brew formula
via <code>brew install telepresenceio/telepresence/telepresence-oss</code>.
docs: https://github.com/telepresenceio/telepresence/issues/3609
- type: feature
title: Add --create-namespace flag to the telepresence helm install command.
body: >-
A <code>--create-namespace</code> (default <code>true</code>) flag was added to the <code>telepresence helm
install</code> command. No attempt will be made to create a namespace for the traffic-manager if it is explicitly
set to <code>false</code>. The command will then fail if the namespace is missing.
- type: feature
title: Introduce DNS fallback on Windows.
body: >-
A <code>network.defaultDNSWithFallback</code> config option has been introduced on Windows. It will cause the
DNS-resolver to fall back to the resolver that was first in the list prior to when Telepresence establishes a
connection. The option is default <code>true</code> since it is believed to give the best experience but can be
set to <code>false</code> to restore the old behavior.
- type: feature
title: Brew now supports MacOS (amd64/arm64) / Linux (amd64)
body: >-
The brew formula can now dynamically support MacOS (amd64/arm64) / Linux (amd64) in a single formula
docs: https://github.com/datawire/homebrew-blackbird/issues/19
- type: feature
title: Add ability to provide an externally-provisioned webhook secret
body: >-
Added <code>supplied</code> as a new option for <code>agentInjector.certificate.method</code>.
This fully disables the generation of the Mutating Webhook's secret, allowing the chart to use the values of a
pre-existing secret named <code>agentInjector.secret.name</code>. Previously, the install would fail when it
attempted to create or update the externally-managed secret.
- type: feature
title: Let PTR query for DNS server return the cluster domain.
body: >-
The <code>nslookup</code> program on Windows uses a PTR query to retrieve its displayed "Server" property.
This Telepresence DNS resolver will now return the cluster domain on such a query.
- type: feature
title: Add scheduler name to PODs templates.
body: >-
A new Helm chart value <code>schedulerName</code> has been added. With this feature, we are
able to define some particular schedulers from Kubernetes to apply some different strategies to allocate telepresence resources,
including the Traffic Manager and hooks pods.
- type: bugfix
title: Race in traffic-agent injector when using inject annotation
body: >-
Applying multiple deployments that used the <code>telepresence.getambassador.io/inject-traffic-agent: enabled</code> would cause
a race condition, resulting in a large number of created pods that eventually had to be deleted, or sometimes in
pods that didn't contain a traffic agent.
- type: bugfix
title: Fix configuring custom agent security context
body: ->
The traffic-manager helm chart will now correctly use a custom agent security context if one is provided.
- version: 2.19.0
date: "2024-06-15"
notes:
- type: feature
title: Warn when an Open Source Client connects to an Enterprise Traffic Manager.
body: >-
The difference between the OSS and the Enterprise offering is not well understood, and OSS users often install
a traffic-manager using the Helm chart published at getambassador.io. This Helm chart installs an enterprise
traffic-manager, which is probably not what the user would expect. Telepresence will now warn when an OSS client
connects to an enterprise traffic-manager and suggest switching to an enterprise client, or use
<code>telepresence helm install</code> to install an OSS traffic-manager.
- type: feature
title: Add scheduler name to PODs templates.
body: >-
A new Helm chart value <code>schedulerName</code> has been added. With this feature, we are
able to define some particular schedulers from Kubernetes to apply some different strategies to allocate telepresence resources,
including the Traffic Manager and hooks pods.
- type: bugfix
title: Improve traffic-manager performance in very large clusters.
body: ->
The traffic-manager will now use a shared-informer when keeping track of deployments. This will significantly
reduce the load on the Kublet in large clusters and therefore lessen the risk for the traffic-manager being
throttled, which can lead to other problems.
- type: bugfix
title: Kubeconfig exec authentication failure when connecting with --docker from a WSL linux host
body: >-
Clusters like Amazon EKS often use a special authentication binary that is declared in the kubeconfig using an
<code>exec</code> authentication strategy. This binary is normally not available inside a container. Consequently,
a modified kubeconfig is used when <code>telepresence connect --docker</code> executes, appointing a <code>kubeauth
</code> binary which instead retrieves the authentication from a port on the Docker host that communicates with another
process outside of Docker. This process then executes the original <code>exec</code> command to retrieve the necessary
credentials.
This setup was problematic when using WSL, because even though <code>telepresence connect --docker</code> was executed on
a Linux host, the Docker host available from <code>host.docker.internal</code> that the <code>kubeauth</code> connected to
was the Windows host running Docker Desktop. The fix for this was to use the local IP of the default route instead of
<code>host.docker.internal</code> when running under WSL..
- version: 2.18.6
date: (SUPERSEDED)
notes:
- type: bugfix
title: Fix bug in workload cache, causing endless recursion when a workload uses the same name as its owner.
body: >-
The workload cache was keyed by name and namespace, but not by kind, so a workload named the same as its
owner workload would be found using the same key. This led to the workload finding itself when looking up
its owner, which in turn resulted in an endless recursion when searching for the topmost owner.
- type: bugfix
title: FailedScheduling events mentioning node availability considered fatal when waiting for agent to arrive.
body: >-
The traffic-manager considers some events as fatal when waiting for a traffic-agent to arrive after an injection
has been initiated. This logic would trigger on events like "Warning FailedScheduling 0/63 nodes are
available" although those events indicate a recoverable condition and kill the wait. This is now fixed so
that the events are logged but the wait continues.
- version: 2.18.5
date: (SUPERSEDED)
notes:
- type: bugfix
title: Improve how the traffic-manager resolves DNS when no agent is installed.
body: >-
The traffic-manager is typically installed into a namespace different from the one that clients are
connected to. It's therefore important that the traffic-manager adds the client's namespace when
resolving single label names in situations where there are any agents to dispatch the DNS query to.
- type: change
title: Removal of ability import legacy artifact into Helm.
body: >-
A helm install would make attempts to find manually installed artifacts and make them managed by
Helm by adding the necessary labels and annotations. This was important when the Helm chart was first
introduced but is far less so today, and this legacy import was therefore removed.
- type: bugfix
title: Docker aliases deprecation caused failure to detect Kind cluster.
body: >-
The logic for detecting if a cluster is a local Kind cluster, and therefore needs some special attention when
using <code>telepresence connect --docker</code>, relied on the presence of <code>Aliases</code> in the Docker
network that a Kind cluster sets up. In Docker versions from 26 and up, this value is no longer used, but the
corresponding info can instead be found in the new <code>DNSNames</code> field.
docs: https://docs.docker.com/engine/deprecated/#container-short-id-in-network-aliases-field
- type: bugfix
title: Include svc as a top-level domain in the DNS resolver.
body: >-
It's not uncommon that use-cases involving Kafka or other middleware use FQNs that end with
"svc". The core-DNS resolver in Kubernetes can resolve such names. With this bugfix,
the Telepresence DNS resolver will also be able to resolve them, and thereby remove the need
to add ".svc" to the include-suffix list.
docs: https://github.com/telepresenceio/telepresence/issues/2814
- type: feature
title: Add ability to enable/disable the mutating webhook.
body: >-
A new Helm chart boolean value <code>agentInjector.enable</code> has been added that controls the agent-injector
service and its associated mutating webhook. If set to <code>false</code>, the service, the webhook, and the
secrets and certificates associated with it, will no longer be installed.
- type: feature
title: Add ability to mount a webhook secret.
body: >-
A new Helm chart value <code>agentInjector.certificate.accessMethod</code> which can be set to <code>watch</code>
(the default) or <code>mount</code> has been added. The <code>mount</code> setting is intended for clusters with
policies that prevent containers from doing a <code>get</code>, <code>list</code> or <code>watch</code> of a
<code>Secret</code>, but where a latency of up to 90 seconds is acceptable between the time the secret is
regenerated and the agent-injector picks it up.
- type: feature
title: Make it possible to specify ignored volume mounts using path prefix.
body: >-
Volume mounts like <code>/var/run/secrets/kubernetes.io</code> are not declared in the workload. Instead, they
are injected during pod-creation and their names are generated. It is now possible to ignore such mounts using a
matching path prefix.
- type: feature
title: Make the telemount Docker Volume plugin configurable
body: >-
A <code>telemount</code> object was added to the <code>intercept</code> object in <code>config.yml</code>
(or Helm value <code>client.intercept</code>), so that the automatic download and installation of this plugin can
be fully customised.
- type: feature
title: Add option to load the kubeconfig yaml from stdin during connect.
body: >-
This allows another process with a kubeconfig already loaded in memory
to directly pass it to <code>telepresence connect</code> without needing a separate
file. Simply use a dash "-" as the filename for the <code>--kubeconfig</code> flag.
- type: feature
title: Add ability to specify agent security context.
body: >-
A new Helm chart value <code>agent.securityContext</code> that will allow configuring the security context of
the injected traffic agent. The value can be set to a valid Kubernetes securityContext object, or can be set
to an empty value (<code>{}</code>) to ensure the agent has no defined security context. If no value is specified,
the traffic manager will set the agent's security context to the same as the first container's of the workload
being injected into.
- type: change
title: Tracing is no longer enabled by default.
body: >-
Tracing must now be enabled explicitly in order to use the <code>telepresence gather-traces</code>
command.
- type: change
title: Removal of timeouts that are no longer in use
body: >-
The <code>config.yml</code> values <code>timeouts.agentInstall</code> and <code>timeouts.apply</code> haven't
been in use since versions prior to 2.6.0, when the client was responsible for installing the traffic-agent.
These timeouts are now removed from the code-base, and a warning will be printed when attempts are made to use
them.
- type: bugfix
title: Search all private subnets to find one open for dnsServerSubnet
body: >-
This resolves a bug that did not test all subnets in a private range, sometimes resulting in the warning,
"DNS doesn't seem to work properly."
- version: 2.18.4
date: (SUPERSEDED)
notes:
- type: bugfix
title: Docker aliases deprecation caused failure to detect Kind cluster.
body: >-
The logic for detecting if a cluster is a local Kind cluster, and therefore needs some special attention when
using <code>telepresence connect --docker</code>, relied on the presence of <code>Aliases</code> in the Docker
network that a Kind cluster sets up. In Docker versions from 26 and up, this value is no longer used, but the
corresponding info can instead be found in the new <code>DNSNames</code> field.
- version: 2.18.3
date: (SUPERSEDED)
notes:
- type: bugfix
title: Creation of individual pods was blocked by the agent-injector webhook.
body: >-
An attempt to create a pod was blocked unless it was provided by a workload. Hence, commands like
<code>kubectl run -i busybox --rm --image=curlimages/curl --restart=Never -- curl echo-easy.default</code>
would be blocked from executing.
- version: 2.18.2
date: (SUPERSEDED)
notes:
- type: bugfix
title: Fix panic due to root daemon not running.
body: >-
If a <code>telepresence connect</code> was made at a time when the root daemon was not running (an abnormal
condition) and a subsequent intercept was then made, a panic would occur when the port-forward to the agent
was set up. This is now fixed so that the initial <code>telepresence connect</code> is refused unless the root
daemon is running.
- version: 2.18.1
date: (SUPERSEDED)
notes:
- type: bugfix
title: Get rid of telemount plugin stickiness
body: >-
The <code>datawire/telemount</code> that is automatically downloaded and installed, would never be
updated once the installation was made. Telepresence will now check for the latest release of the
plugin and cache the result of that check for 24 hours. If a new version arrives, it will be
installed and used.
- type: bugfix
title: Use route instead of address for CIDRs with masks that don't allow "via"
body: >-
A CIDR with a mask that leaves less than two bits (/31 or /32 for IPv4)
cannot be added as an address to the VIF, because such addresses must
have bits allowing a "via" IP.
The logic was modified to allow such CIDRs to become static routes, using the
VIF base address as their "via", rather than being VIF addresses in their own right.
- type: bugfix
title: Containerized daemon created cache files owned by root
body: >-
When using <code>telepresence connect --docker</code> to create a containerized daemon, that
daemon would sometimes create files in the cache that were owned by root, which then caused
problems when connecting without the <code>--docker</code> flag.
- type: bugfix
title: Remove large number of requests when traffic-manager is used in large clusters.
body: >-
The traffic-manager would make a very large number of API requests during cluster start-up
or when many services were changed for other reasons. The logic that did this was refactored
and the number of queries were significantly reduced.
- type: bugfix
title: Don't patch probes on replaced containers.
body: >-
A container that is being replaced by a <code>telepresence intercept --replace</code>
invocation will have no liveness-, readiness, nor startup-probes. Telepresence didn't
take this into consideration when injecting the traffic-agent, but now it will refrain
from patching symbolic port names of those probes.
- type: bugfix
title: Don't rely on context name when deciding if a kind cluster is used.
body: >-
The code that auto-patches the kubeconfig when connecting to a kind cluster from within
a docker container, relied on the context name starting with "kind-", but although all
contexts created by kind have that name, the user is still free to rename it or to create
other contexts using the same connection properties. The logic was therefore changed
to instead look for a loopback service address.
- version: 2.18.0
date: "2024-02-09"
notes:
- type: feature
title: Include the image for the traffic-agent in the output of the version and status commands.
body: >-
The version and status commands will now output the image that the traffic-agent will be using when injected
by the agent-injector.
- type: feature
title: Custom DNS using the client DNS resolver.
body: >-
<p>A new <code>telepresence connect --proxy-via CIDR=WORKLOAD</code> flag was introduced, allowing Telepresence
to translate DNS responses matching specific subnets into virtual IPs that are used locally. Those virtual IPs
are then routed (with reverse translation) via the pod's of a given workload. This makes it possible to handle
custom DNS servers that resolve domains into loopback IPs. The flag may also be used in cases where the
cluster's subnets are in conflict with the workstation's VPN.</p>
<p>The CIDR can also be a symbolic name that identifies a subnet or list of subnets:</p><table><tbody>
<tr><td><code>also</code></td><td>All subnets added with --also-proxy</td></tr>
<tr><td><code>service</code></td><td>The cluster's service subnet</td></tr>
<tr><td><code>pods</code></td><td>The cluster's pod subnets.</td></tr>
<tr><td><code>all</code></td><td>All of the above.</td></tr>
</tbody></table>
- type: bugfix
title: Ensure that agent.appProtocolStrategy is propagated correctly.
body: >-
The <code>agent.appProtocolStrategy</code> was inadvertently dropped when moving license related code fromm the
OSS repository the repository for the Enterprise version of Telepresence. It has now been restored.
- type: bugfix
title: Include non-default zero values in output of telepresence config view.
body: >-
The <code>telepresence config view</code> command will now print zero values in the output when
the default for the value is non-zero.
- type: bugfix
title: Restore ability to run the telepresence CLI in a docker container.
body: >-
The improvements made to be able to run the telepresence daemon in docker
using <code>telepresence connect --docker</code> made it impossible to run
both the CLI and the daemon in docker. This commit fixes that and
also ensures that the user- and root-daemons are merged in this
scenario when the container runs as root.
- type: bugfix
title: Remote mounts when intercepting with the --replace flag.
body: >-
A <code>telepresence intercept --replace</code> did not correctly mount all volumes, because when the
intercepted container was removed, its mounts were no longer visible to the agent-injector when it
was subjected to a second invocation. The container is now kept in place, but with an image that
just sleeps infinitely.
- type: bugfix
title: Intercepting with the --replace flag will no longer require all subsequent intercepts to use --replace.
body: >-
A <code>telepresence intercept --replace</code> will no longer switch the mode of the intercepted workload,
forcing all subsequent intercepts on that workload to use <code>--replace</code> until the agent is
uninstalled. Instead, <code>--replace</code> can be used interchangeably just like any other intercept flag.
- type: bugfix
title: Kubeconfig exec authentication with context names containing colon didn't work on Windows
body: >-
The logic added to allow the root daemon to connect directly to the cluster using the user daemon as a proxy
for exec type authentication in the kube-config, didn't take into account that a context name sometimes
contains the colon ":" character. That character cannot be used in filenames on windows because it is the
drive letter separator.
- type: bugfix
title: Provide agent name and tag as separate values in Helm chart
body: >-
The <code>AGENT_IMAGE</code> was a concatenation of the agent's name and tag. This is now changed so that the
env instead contains an <code>AGENT_IMAGE_NAME</code> and <code>AGENT_INAGE_TAG</code>. The <code>AGENT_IMAGE
</code> is removed. Also, a new env <code>REGISTRY</code> is added, where the registry of the traffic-
manager image is provided. The <code>AGENT_REGISTRY</code> is no longer required
and will default to <code>REGISTRY</code> if not set.
- type: bugfix
title: Environment interpolation expressions were prefixed twice.
body: >-
Telepresence would sometimes prefix environment interpolation expressions in the traffic-agent twice so
that an expression that looked like <code>$(SOME_NAME)</code> in the app-container, ended up as <code>
$(_TEL_APP_A__TEL_APP_A_SOME_NAME)</code> in the corresponding expression in the traffic-agent.
- type: bugfix
title: Panic in root-daemon on darwin workstations with full access to cluster network.
body: >-
A darwin machine with full access to the cluster's subnets will never create a TUN-device, and a check was
missing if the device actually existed, which caused a panic in the root daemon.
- type: bugfix
title: Show allow-conflicting-subnets in telepresence status and telepresence config view.
body: >-
The <code>telepresence status</code> and <code>telepresence config view</code> commands didn't show the
<code>allowConflictingSubnets</code> CIDRs because the value wasn't propagated correctly to the CLI.
- type: feature
title: It is now possible use a host-based connection and containerized connections simultaneously.
body: >-
Only one host-based connection can exist because that connection will alter the DNS to reflect the namespace
of the connection. but it's now possible to create additional connections using <code>--docker</code> while
retaining the host-based connection.
- type: feature
title: Ability to set the hostname of a containerized daemon.
body: >-
The hostname of a containerized daemon defaults to be the container's ID in Docker. You now can override the
hostname using <code>telepresence connect --docker --hostname <a name></code>.
- type: feature
title: New <code>--multi-daemon</code>flag to enforce a consistent structure for the status command output.
body: >-
The output of the <code>telepresence status</code> when using <code>--output json</code> or <code>--output
yaml</code> will either show an object where the <code>user_daemon</code> and <code>root_daemon</code>
are top level elements, or when multiple connections are used, an object where a <code>connections</code>
list contains objects with those daemons. The flag <code>--multi-daemon</code> will enforce the latter
structure even when only one daemon is connected so that the output can be parsed consistently. The reason
for keeping the former structure is to retain backward compatibility with existing parsers.
- type: bugfix
title: Make output from telepresence quit more consistent.
body: >-
A quit (without -s) just disconnects the host user and root daemons but will quit a container based daemon.
The message printed was simplified to remove some have/has is/are errors caused by the difference.
- type: bugfix
title: "Fix "tls: bad certificate" errors when refreshing the mutator-webhook secret"
body: >-
The <code>agent-injector</code> service will now refresh the secret used by the <code>mutator-webhook</code>
each time a new connection is established, thus preventing the certificates to go out-of-sync when
the secret is regenerated.
- type: bugfix
title: Keep telepresence-agents configmap in sync with pod states.
body: >-
An intercept attempt that resulted in a timeout due to failure of injecting the traffic-agent left the
<code>telepresence-agents</code> configmap in a state that indicated that an agent had been added, which
caused problems for subsequent intercepts after the problem causing the first failure had been fixed.
- type: bugfix
title: The <code>telepresence status</code> command will now report the status of all running daemons.
body: >-
A <code>telepresence status</code>, issued when multiple containerized daemons were active, would error with
"multiple daemons are running, please select one using the --use <match> flag". This is now
fixed so that the command instead reports the status of all running daemons.
- type: bugfix
title: The <code>telepresence version</code> command will now report the version of all running daemons.
body: >-
A <code>telepresence version</code>, issued when multiple containerized daemons were active, would error with
"multiple daemons are running, please select one using the --use <match> flag". This is now
fixed so that the command instead reports the version of all running daemons.
- type: bugfix
title: Multiple containerized daemons can now be disconnected using <code>telepresence quit -s</code>
body: >-
A <code>telepresence quit -s</code>, issued when multiple containerized daemons were active, would error with
"multiple daemons are running, please select one using the --use <match> flag". This is now
fixed so that the command instead quits all daemons.
- type: bugfix
title: The DNS search path on Windows is now restored when Telepresence quits
body: >-
The DNS search path that Telepresence uses to simulate the DNS lookup functionality in the connected
cluster namespace was not removed by a <code>telepresence quit</code>, resulting in connectivity problems
from the workstation. Telepresence will now remove the entries that it has added to the search list when
it quits.
- type: bugfix
title: The user-daemon would sometimes get killed when used by multiple simultaneous CLI clients.
body: >-
The user-daemon would die with a fatal "fatal error: concurrent map writes" error in the
<code>connector.log</code>, effectively killing the ongoing connection.
- type: bugfix
title: Multiple services ports using the same target port would not get intercepted correctly.
body: >-
Intercepts didn't work when multiple service ports were using the same container port. Telepresence would
think that one of the ports wasn't intercepted and therefore disable the intercept of the container port.
- type: bugfix
title: Root daemon refuses to disconnect.
body: >-
The root daemon would sometimes hang forever when attempting to disconnect due to a deadlock in
the VIF-device.
- type: bugfix
title: Fix panic in user daemon when traffic-manager was unreachable
body: >-
The user daemon would panic if the traffic-manager was unreachable. It will now instead report
a proper error to the client.
- type: change
title: Removal of backward support for versions predating 2.6.0
body: >-
The telepresence helm installer will no longer discover and convert workloads that were modified by versions
prior to 2.6.0. The traffic manager will and no longer support the muxed tunnels used in versions prior to
2.5.0.
- version: 2.17.0
date: "2023-11-14"
notes:
- type: feature
title: Additional Prometheus metrics to track intercept/connect activity
body: >-
This feature adds the following metrics to the Prometheus endpoint: <code>connect_count</code>,
<code>connect_active_status</code>, <code>intercept_count</code>, and <code>intercept_active_status</code>.
These are labeled by client/install_id.
Additionally, the <code>intercept_count</code> metric has been renamed to <code>active_intercept_count</code>
for clarity.
- type: feature
title: Make the Telepresence client docker image configurable.
body: >-
The docker image used when running a Telepresence intercept in docker mode can now be configured using
the setting <code>images.clientImage</code> and will default first to the value of the environment <code>
TELEPRESENCE_CLIENT_IMAGE</code>, and then to the value preset by the telepresence binary. This
configuration setting is primarily intended for testing purposes.
- type: feature
title: Use traffic-agent port-forwards for outbound and intercepted traffic.
body: >-
The telepresence TUN-device is now capable of establishing direct port-forwards to a traffic-agent in the
connected namespace. That port-forward is then used for all outbound traffic to the device, and also for
all traffic that arrives from intercepted workloads. Getting rid of the extra hop via the traffic-manager
improves performance and reduces the load on the traffic-manager. The feature can only be used if the client
has Kubernetes port-forward permissions to the connected namespace. It can be disabled by setting <code>
cluster.agentPortForward</code> to <code>false</code> in <code>config.yml</code>.
- type: feature
title: Improve outbound traffic performance.
body: >-
The root-daemon now communicates directly with the traffic-manager instead of routing all outbound traffic
through the user-daemon. The root-daemon uses a patched kubeconfig where <code>exec</code> configurations to
obtain credentials are dispatched to the user-daemon. This to ensure that all authentication plugins will
execute in user-space. The old behavior of routing everything through the user-daemon can be restored by
setting <code>cluster.connectFromRootDaemon</code> to <code>false</code> in <code>config.yml</code>.
- type: feature
title: New networking CLI flag --allow-conflicting-subnets
body: >-
telepresence connect (and other commands that kick off a connect) now accepts an --allow-conflicting-subnets
CLI flag. This is equivalent to client.routing.allowConflictingSubnets in the helm chart, but can be specified
at connect time. It will be appended to any configuration pushed from the traffic manager.
- type: change
title: Warn if large version mismatch between traffic manager and client.
body: >-
Print a warning if the minor version diff between the client and the traffic manager is greater than three.
- type: change
title: The authenticator binary was removed from the docker image.
body: >-
The <code>authenticator</code> binary, used when serving proxied <code>exec</code> kubeconfig credential
retrieval, has been removed. The functionality was instead added as a subcommand to the <code>telepresence
</code> binary.
- version: 2.16.1
date: "2023-10-12"
notes:
- type: feature
title: Add --docker-debug flag to the telepresence intercept command.
body: >-
This flag is similar to <code>--docker-build</code> but will start the container with more relaxed security
using the <code>docker run</code> flags <code>--security-opt apparmor=unconfined --cap-add SYS_PTRACE</code>.
- type: feature
title: Add a --export option to the telepresence connect command.
body: >-
In some situations it is necessary to make some ports available to the
host from a containerized telepresence daemon. This commit adds a
repeatable <code>--expose <docker port exposure></code> flag to the connect
command.
- type: feature
title: Prevent agent-injector webhook from selecting from kube-xxx namespaces.
body: >-
The <code>kube-system</code> and <code>kube-node-lease</code> namespaces should not be affected by a
global agent-injector webhook by default. A default <code>namespaceSelector</code> was therefore added
to the Helm Chart <code>agentInjector.webhook</code> that contains a <code>NotIn</code> preventing those
namespaces from being selected.
- type: bugfix
title: Backward compatibility for pod template TLS annotations.
body: >-
Users of Telepresence < 2.9.0 that make use of the pod template TLS annotations were unable to upgrade because
the annotation names have changed (now prefixed by "telepresence."), and the environment expansion of the
annotation values was dropped. This fix restores support for the old names (while retaining the new ones) and
the environment expansion.
- type: security
title: Built with go 1.21.3
body: >-
Built Telepresence with go 1.21.3 to address CVEs.
- type: bugfix
title: Match service selector against pod template labels
body: >-
When listing intercepts (typically by calling <code>telepresence list</code>) selectors of services are matched
against workloads. Previously the match was made against the labels of the workload, but now they are matched
against the labels pod template of the workload. Since the service would actually be matched against pods this
is more correct. The most common case when this makes a difference is that statefulsets now are listed when they should.
- version: 2.16.0
date: "2023-10-02"
notes:
- type: bugfix
title: The helm sub-commands will no longer start the user daemon.
body: >-
The <code>telepresence helm install/upgrade/uninstall</code> commands will no longer start the telepresence
user daemon because there's no need to connect to the traffic-manager in order for them to execute.
- type: bugfix
title: Routing table race condition
body: >-
A race condition would sometimes occur when a Telepresence TUN device was deleted and another created in rapid
succession that caused the routing table to reference interfaces that no longer existed.
- type: bugfix
title: Stop lingering daemon container
body: >-
When using <code>telepresence connect --docker</code>, a lingering container could be present, causing errors
like "The container name NN is already in use by container XX ...". When this happens, the connect
logic will now give the container some time to stop and then call <code>docker stop NN</code> to stop it
before retrying to start it.
- type: bugfix
title: Add file locking to the Telepresence cache
body: >-
Files in the Telepresence cache are accesses by multiple processes. The processes will now use advisory
locks on the files to guarantee consistency.
- type: change
title: Lock connection to namespace
body: >-
The behavior changed so that a connected Telepresence client is bound to a namespace. The namespace can then
not be changed unless the client disconnects and reconnects. A connection is also given a name. The default
name is composed from <code><kube context name>-<namespace></code> but can be given explicitly
when connecting using <code>--name</code>. The connection can optionally be identified using the option
<code>--use <name match></code> (only needed when docker is used and more than one connection is active).
- type: change
title: Deprecation of global --context and --docker flags.
body: >-
The global flags <code>--context</code> and <code>--docker</code> will now be considered deprecated unless used
with commands that accept the full set of Kubernetes flags (e.g. <code>telepresence connect</code>).
- type: change
title: Deprecation of the --namespace flag for the intercept command.
body: >-
The <code>--namespace</code> flag is now deprecated for <code>telepresence intercept</code> command. The flag can instead
be used with all commands that accept the full set of Kubernetes flags (e.g. <code>telepresence connect</code>).
- type: change
title: Legacy code predating version 2.6.0 was removed.
body: >-
The telepresence code-base still contained a lot of code that would modify workloads instead of relying on
the mutating webhook installer when a traffic-manager version predating version 2.6.0 was discovered. This
code has now been removed.
- type: feature
title: Add `telepresence list-namespaces` and `telepresence list-contexts` commands
body: >-
These commands can be used to check accessible namespaces and for automation.
- type: change
title: Implicit connect warning
body: >-
A deprecation warning will be printed if a command other than <code>telepresence connect</code> causes an
implicit connect to happen. Implicit connects will be removed in a future release.
- version: 2.15.1
date: "2023-09-06"
notes:
- type: security