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.9 backports 2020-12-08 #14308

Merged
merged 7 commits into from
Dec 11, 2020
Merged

v1.9 backports 2020-12-08 #14308

merged 7 commits into from
Dec 11, 2020

Conversation

fristonio
Copy link
Member

@fristonio fristonio commented Dec 8, 2020

Edit:

Dropped due to verifier complexity issues:

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

$ for pr in 14278 14262 14264 14237 14153 14295 14257; do contrib/backporting/set-labels.py $pr done 1.9; done

@fristonio fristonio requested a review from a team as a code owner December 8, 2020 16:20
@fristonio fristonio added backport/1.9 kind/backports This PR provides functionality previously merged into master. labels Dec 8, 2020
Copy link
Member

@pchaigno pchaigno left a comment

Choose a reason for hiding this comment

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

👍 for my PR.

Copy link
Member

@gandro gandro left a comment

Choose a reason for hiding this comment

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

Looks good for my changes

@fristonio
Copy link
Member Author

test-backport-1.9

errordeveloper and others added 7 commits December 10, 2020 13:09
[ upstream commit bc29693 ]

Fixes: 992c321 ("docs/gettingstarted: Update AKS guide")

Signed-off-by: Ilya Dmitrichenko <errordeveloper@gmail.com>
Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com>
[ upstream commit c05e2fa ]

The difference between using toRequires+toEndpoints vs.
toEndpoints+toEndpoints (i.e., first is logical AND of the rules whereas
second is OR) is not particularly obvious when first reading the
toRequires documentation.

This commit attempts to clarify this difference by completing the
fromRequires example with a fromEndpoints policy.

Suggested-by: Thomas Graf <thomas@cilium.io>
Signed-off-by: Paul Chaignon <paul@cilium.io>
Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com>
[ upstream commit f15af5e ]

Pip 20.3 introduced a new dependency resolver[[0]] which silently
reinterprets our current requirements file in a different way to
resolve the dependencies, which results the build being broken.

On non-aarch64 systems, there are two requirements that satisfy
the sphinx-rtd-theme package:
* One provided by our own theme repository[[1]] which has nice consistent
  theming for the website, and
* One provided by the upstream sphinx-rtd-theme package.

Prior to pip 20.3, the default resolver was able to resolve this
conflict to favour our custom theme, which is the one we intend to use
in most cases. Unfortunately, with the new resolver, this conflict is
resolved the other way. As far as I can tell, there is no "strict" mode
to prescribe that pip should resolve conflicts first and fail out if the
requirements are ambiguous. Instead, pip silently resolves this conflict
and we do not find out that there was ambiguity until later in the
process.

In addition, on readthedocs.org, new versions of pip are automatically
pulled upon each new docs build, which meant that from one day to the
next, a previously successful build began to consistently fail with
weird errors that imply a problem with the dependency but don't explain
why the problem was introduced without changes to code in our build
system:

  Theme error:
  no theme named 'sphinx_rtd_theme_cilium' found (missing theme.conf?)
  make[1]: *** [Makefile:48: html] Error 2
  make: *** [Makefile:552: test-docs] Error 2

Fix the issue by disambiguating the theme dependency.

[0]: http://pyfound.blogspot.com/2020/11/pip-20-3-new-resolver.html
[1]: https://github.com/cilium/sphinx_rtd_theme

Fixes: #14252

Signed-off-by: Joe Stringer <joe@cilium.io>
Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com>
[ upstream commit 7c616b6 ]

Commit c29b3ac ("ugrade-guide: add example") added an example, but
didn't update the existing values example to match it which was slightly
confusing. Clarify the values.yaml example to make the options the same.

Signed-off-by: Joe Stringer <joe@cilium.io>
Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com>
[ upstream commit 0e3dfc6 ]

Previously, tunnel and ipam key were set twice if gke.enabled
was set true. This commit adds a check around tunnel key, so
as to ensure that it is set only once according to the value
of .Values.gke.enabled .

To deduplicate ipam key, we are removing it from the code block
that sets the keys if gke is enabled. This makes sure that
ipam key is set only once in cilium-configmap.yaml, and requires
users to explicitly set ipam using ipam.mode, if they wish to
set it to something other than 'cluster-pool'.

Fixes: #13999

Signed-off-by: Pranavi Roy <pranavi@accuknox.com>
Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com>
[ upstream commit bc126ef ]

This commit fixes the preflight check on GKE which currently conflicts
with the resource quotas that may be present from an already installed
Cilium version:

```
Error: rendered manifests contain a resource that already exists. Unable
to continue with install: existing resource conflict: kind:
ResourceQuota, namespace: cilium, name: cilium-resource-quota
```

Fixes: 14ff743 ("gke: add resource quotas for Cilium namespace")

Signed-off-by: Sebastian Wicki <sebastian@isovalent.com>
Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com>
[ upstream commit 81afb1c ]

This brings back the GetRealizedPolicyRuleLabelsForKey helper which is
used by external client code and was accidentally removed as unused.
This commit also extends the Hubble unit tests to invoke it, to avoid
another accidental removal.

Fixes: 0ba1967 ("pkg/endpoint: remove unused functions")

Signed-off-by: Sebastian Wicki <sebastian@isovalent.com>
Signed-off-by: Deepesh Pathak <deepshpathak@gmail.com>
@fristonio
Copy link
Member Author

test-backport-1.9

@fristonio
Copy link
Member Author

retest-runtime

@fristonio
Copy link
Member Author

retest-gke

@joestringer joestringer added the ready-to-merge This PR has passed all tests and received consensus from code owners to merge. label Dec 10, 2020
@jrajahalme jrajahalme merged commit b565953 into v1.9 Dec 11, 2020
@jrajahalme jrajahalme deleted the pr/v1.9-backport-2020-12-08 branch December 11, 2020 04:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/backports This PR provides functionality previously merged into master. ready-to-merge This PR has passed all tests and received consensus from code owners to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants