Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.14 backports 2023-07-25 #27069

Merged
merged 14 commits into from Jul 26, 2023
Merged

Conversation

joestringer
Copy link
Member

@joestringer joestringer commented Jul 25, 2023

Once this PR is merged, you can update the PR labels via:

$ for pr in 26788 26846 26892 ; do contrib/backporting/set-labels.py $pr done 1.14; done

giorio94 and others added 14 commits July 25, 2023 14:39
[ upstream commit 6dde6be ]

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit b94688d ]

Currently, the remote cluster status reports the number of nodes,
identities and services synchronized from any given remote cluster.
Let's additionally expose the number of endpoints. Please note that
a pod with two IP addresses (e.g., one IPv4 and another IPv6 counts
as two separate endpoints).

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit e206c47 ]

Enrich the remote cluster status to additionally include information
about the cluster configuration advertised by the remote cluster. In
particular, whether it is required to be present and has been retrieved,
along with the remote cluster ID and its capabilities. By default, this
information is shown only until the given cluster is not ready, or if
the `--all-clusters` flag is set, to simplify troubleshooting possible
issues and distinguish them from connectivity problems.

The information concerning the cluster configuration to be returned as
part of the status is stored remote cluster during the retrieval process,
initially setting whether it is required to be present, and then filling
the rest of the fields when it is actually retrieved. No cluster config
information is returned if the retrieval process has not started yet.

Additionally, this commit slightly modifies the condition used to
determine whether a given cluster is reported as ready, requiring that
the connection to the remote etcd has been established, and the cluster
configuration has either been retrieved, or determined that it is not
required to be present. Hence, no longer relying on the connection status
only, which was previously configured only after retrieving the cluster
configuration, possibly leading to a more inaccurate status reporting.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit fd9b1e6 ]

Currently, the synced variable is used in the RestartableWatchStore
to ensure that callbacks are executed only once upon the initial
synchronization. Given that a subsequent commit will start exposing
synchronization information (with a different meaning), let's get rid
of it and rework the callbacks execution to not depend on it.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit d9a024b ]

Let's allow to retrieve whether the RestartableWatchStore is currently
synchronized or not. It is considered to be synchronized if the initial
list of entries has been retrieved from the kvstore, and new events are
being watched. When the watch operation gets interrupted, the status
transitions back to not synchronized.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit 7303c59 ]

Let's allow to retrieve whether the ipcache watcher is currently
synchronized, based on the status of the underlying watch store.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit bc66a43 ]

Let's allow to retrieve whether the remote identities cache is currently
synchronized or not. It is considered to be synchronized if the initial
list of entries has been retrieved from the kvstore, and new events are
being watched. When the watch operation gets interrupted, the status
transitions back to not synchronized.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit 5b34dd6 ]

Enrich the remote cluster status to additionally include information
concerning the synchronization status of each resource type. In
particular, a resource type is considered to be synchronized if the
initial list of entries has been completely received from the remote
cluster, and new events are currently being watched.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit 0c2b88a ]

Currently, the remote cluster status is reported as ready once the
kvstore connection has been established. Let's extend this to also
wait for the initial synchronization to complete for each watched
resource type.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit 81f2d3a ]

Currently, the remote cluster status includes a ready field, as well as
the information about the connection to the remote kvstore in textual
form. While this is enough for a human to distinguish whether it is
reported as not ready due to the kvstore connection not being ready
or not (e.g., the synchronization process being still in progress),
it is confusing when retrieved externally, for instance by the Cilium
CLI. Hence, let's add an explicit flag to known whether the connection
to the remote kvstore has been established or not.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit 46c57f9 ]

Update the clustermesh troubleshooting page to reflect the output of the
extended `cilium status --all-clusters` command.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit 185df80 ]

The output of the `cilium clustermesh status --wait` command has
slightly changed to fix an inaccuracy. Let's reflect it also here.

Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit 9e01ae0 ]

When an EgressGW policy was updated to select a different egress interface,
delete all IP rules that still point to the old interface.

Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
[ upstream commit 2390916 ]

Previously search input didn't work on some pages,
updated docs theme should fix this.

Closes cilium#26866

Signed-off-by: Dmitry Kharitonov <dmitry@isovalent.com>
Signed-off-by: Joe Stringer <joe@cilium.io>
@joestringer joestringer requested review from a team as code owners July 25, 2023 21:40
@joestringer joestringer added kind/backports This PR provides functionality previously merged into master. backport/1.14 This PR represents a backport for Cilium 1.14.x of a PR that was merged to main. labels Jul 25, 2023
@joestringer
Copy link
Member Author

/test-backport-1.14

Copy link
Member

@giorio94 giorio94 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@aanm aanm merged commit f78778a into cilium:v1.14 Jul 26, 2023
64 checks passed
@joestringer joestringer deleted the pr/v1.14-backport-2023-07-25 branch July 27, 2023 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport/1.14 This PR represents a backport for Cilium 1.14.x of a PR that was merged to main. kind/backports This PR provides functionality previously merged into master.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants