-
Notifications
You must be signed in to change notification settings - Fork 100
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
[WIP] 1.25 rebase #1367
[WIP] 1.25 rebase #1367
Conversation
…nges Update CRI API to support Evented PLEG
…ges for kubelet client and serving certificates Signed-off-by: Paco Xu <paco.xu@daocloud.io>
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
It is used to request that a pod runs in a unique user namespace. Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com> Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com> Co-authored-by: Rodrigo Campos <rodrigoca@microsoft.com>
Move e2e test from alpha with feature promoted to beta
…ment Allow retroactive storage class assigment to PVCs
KEP: /enhancements/keps/sig-node/1287-in-place-update-pod-resources
Promote CronJobTimeZone to beta
Change-Id: I3be351fb3b53216948a37b1d58224f8fbbf22b47
…uceeded Fix JobTrackingWithFinalizers when a pod succeeds after the job fails
…ional modify the signing/approving controller to tolerate either set of usages for kubelet client and serving certificates
….12.1, kustomize/v4.5.7 (kubernetes#111606)
Signed-off-by: Abirdcfly <fp544037857@gmail.com>
…ertical-scaling-cri CRI changes to support in-place pod resize
This change is to promote local storage capacity isolation feature to GA At the same time, to allow rootless system disable this feature due to unable to get root fs, this change introduced a new kubelet config "localStorageCapacityIsolation". By default it is set to true. For rootless systems, they can set this configuration to false to disable the feature. Once it is set, user cannot set ephemeral-storage request/limit because capacity and allocatable will not be set. Change-Id: I48a52e737c6a09e9131454db6ad31247b56c000a
modify modify modify modify modify
define a feature gate for the user namespaces support. The feature is not enabled by default. Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
e2e: Trim junit reporter to adapt with testgrid
…d-arch-installing-etcd Avoid hard coding Operating System and Architecture in hack/lib/etcd.sh
…im_report Revert "e2e: Trim junit reporter to adapt with testgrid"
Including the full information for successful tests makes the resulting XML file too large for the 200GB limit in Spyglass when running large jobs (like scale testing). The original solution from kubernetes#111627 broke JUnit reporting in other test suites, in particular test/e2e_node. Keeping the code inside the framework ensures that all test suites continue to have the JUnit reporting. AfterReadingAllFlags is a good place to set this up because all test suites using the test context are expected to call it before running tests and after parsing flags. Removing the ReportEntries added by ginkgo.By from all test reports usually avoids the `system-err` part in the JUnit file, which in Spyglass avoids the extra "open stdout" button. Co-authored-by: Patrick Ohly <patrick.ohly@intel.com> Co-authored-by: Dave Chen <dave.chen@arm.com>
Signed-off-by: David Porter <david@porter.me>
This commit just adds a validation according to KEP-127. We check that only the supported volumes for phase 1 of the KEP are accepted. Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
it is used to allocate and keep track of the unique users ranges assigned to each pod that runs in a user namespace. Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com> Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com> Co-authored-by: Rodrigo Campos <rodrigoca@microsoft.com>
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
in 4.12 and higher the default CNI is OVNKubernetes and these two tests do not pass. Skip them. They are also skipping in the origin test suites for ovnk. Signed-off-by: Jamo Luhrsen <jluhrsen@gmail.com>
when we run verify-import-boss.sh it fails with the following error errors in package "k8s.io/kubernetes/cmd/kubeadm/app/phases/bootstraptoken/node": the following imports did not match any allowed prefix: gopkg.in/yaml.v3 k8s.io/kube-openapi/pkg/validation/spec note: this should be an upstream fix, not sure why we don't see this error in upstream, does upstream not run this job in verify? investigate and take proper action for this commit
we encountered a vendor inconsistency error from staging/src/k8s.io/code-generator. in order to fix it: - change direcroty to 'staging/src/k8s.io/code-generator/examples' - open go.mod and add openshift ginkgo in a replace section replace ( github.com/onsi/ginkgo => github.com/openshift/ginkgo xxx ) - go mod tidy - change directory to 'staging/src/k8s.io/code-generator' - open go.mod and add openshift ginkgo in a replace section replace ( github.com/onsi/ginkgo => github.com/openshift/ginkgo xxx ) - go mod tidy - change directory to root of the repo - bump the following openshift repos in the go.mod file - openshift/api - openshift/client-go - openshift/library-go - openshift/apiserver-library-go - github.com/openshift/ginkgo xxxx - go mod tidy - hack/update-vendor.sh
make update fails with the following error due to some go mod issue in code-generator: ``` inconsistent vendoring in /go/{redacted}/k8s.io/code-generator ``` to work around, we do the following: - change directory to 'staging/src/k8s.io/code-generator' - remove the following from the 'replace' section k8s.io/code-generator => ../code-generator - run 'go mod tidy' - run 'go mod vendor' - change directory to root - run make update, using the following command podman run -it --rm -v $( pwd ):/go/src/k8s.io/kubernetes:Z \ --workdir=/go/src/k8s.io/kubernetes \ registry.ci.openshift.org/openshift/release:rhel-8-release-golang-1.18-openshift-4.11 \ make update OS_RUN_WITHOUT_DOCKER=yes inside the docker prompt, also run the followig: - OS_RUN_WITHOUT_DOCKER=yes hack/update-generated-pod-resources.sh
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: kikisdeliveryservice The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
42b474b
to
a17da2e
Compare
Previously using F29 resulted in our job failing, however, attempts at fixing that also hit the same issues as the initial rebase PR. Removing fix to see if this still fails w/ F29 on a machine-os-content failure. |
Testing a payload job that failed in past wrt machine-os-content |
@kikisdeliveryservice: trigger 1 job(s) for the /payload-(job|aggregate) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/17ae4ff0-361b-11ed-97fc-54d89698abd2-0 |
also: |
@kikisdeliveryservice: trigger 0 job(s) for the /payload-(job|aggregate) command |
/payload-job periodic-nightly-4.12-e2e-vsphere-ovn-techpreview-serial periodic-nightly-4.12-e2e-vsphere-ovn-techpreview |
@kikisdeliveryservice: trigger 0 job(s) for the /payload-(job|aggregate) command |
/payload-job periodic-nightly-4.12-e2e-vsphere-ovn-techpreview-serial |
@kikisdeliveryservice: trigger 0 job(s) for the /payload-(job|aggregate) command |
Ok so rebase bump without fixing f29 stills fails: |
@kikisdeliveryservice: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Got the machine-os-image sorted. No longer need this. |
No description provided.