-
Notifications
You must be signed in to change notification settings - Fork 51
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
Cherry pick 1401 to release 0.65 #1411
Conversation
Signed-off-by: Quique Llorente <ellorent@redhat.com>
At a release branch if a component has not release branch itself it has to be marked at static at components.yaml so autobumper will ignore new tags. Signed-off-by: Quique Llorente <ellorent@redhat.com>
Signed-off-by: Quique Llorente <ellorent@redhat.com> Co-authored-by: Quique Llorente <ellorent@redhat.com>
…t#1165) * cluster: Enable just ovs repo (kubevirt#1163) Some openstack repos does not support centos 8 stream yet. This change point directly to the centos 8 stream ovs repo. (cherry picked from commit 152a52e) Signed-off-by: Quique Llorente <ellorent@redhat.com> * go: Bump to 1.16 Signed-off-by: Quique Llorente <ellorent@redhat.com>
Signed-off-by: CNAO Bump Bot <noreply@github.com> Co-authored-by: CNAO Bump Bot <noreply@github.com>
Running all the kubernetes-nmstate tests takes a lot of time and does not bring much value. This change runs the following tests: - Webhooks - OVS - NMPolicy - default bridge and bond Signed-off-by: Quique Llorente <ellorent@redhat.com> Co-authored-by: Quique Llorente <ellorent@redhat.com>
Sometimes HEAD is not there Signed-off-by: Quique Llorente <ellorent@redhat.com>
…o-release-0.65 [release-0.65] release: Use prefixed_released_version
This reverts commit 6f86026.
Now that release can be executed with github actions the process has to be non interactive. Signed-off-by: Quique Llorente <ellorent@redhat.com>
Signed-off-by: Quique Llorente <ellorent@redhat.com>
Right now the release notes comes from the commits, but the info needed is the release-note mark from PRs since users decide if they want that info to appear that the release notes or not. Signed-off-by: Quique Llorente <ellorent@redhat.com>
Looks like the quay.io tag for multus has being re-generated. This changes put the SHA to the correct pointer. Signed-off-by: Quique Llorente <ellorent@redhat.com> Co-authored-by: Quique Llorente <ellorent@redhat.com>
This reverts commit a490654. Signed-off-by: Quique Llorente <ellorent@redhat.com>
Added test of transition of NMState deployment from CNAO to nmstate-operator. Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com> Co-authored-by: Radim Hrazdil <rhrazdil@redhat.com>
Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
Signed-off-by: CNAO Bump Bot <noreply@github.com> Co-authored-by: CNAO Bump Bot <noreply@github.com>
linux-bridge primary branch has changed to main. Updating components.yaml accordingly Signed-off-by: Ram Lavi <ralavi@redhat.com>
Signed-off-by: GitHub <noreply@github.com> Co-authored-by: qinqon <qinqon@users.noreply.github.com>
Signed-off-by: CNAO Bump Bot <noreply@github.com> Co-authored-by: CNAO Bump Bot <noreply@github.com>
…t#1277) CNAO labels the components it deploys with relationship labels. In case the component is in the same namespace of the CNA operator itself, it will be labeled as well. Since K8s logs are labeled with kubernetes.namespace_name according the labels the namespace has, all the cnv logs in the namespace would appear as their kubernetes.io/component equal the value CNAO sets. Same for the other labels that CNAO adds to the namespace. Therefore: Do not add labels to the namespace of the operator itself. In order to guarantee backward compatibility, CNAO will also remove those labels from the operator namespace according to their key. It is safe to do that, because those labels should not be added by anyone, else the problem will reoccur. Affected labels: Relationship labels: app.kubernetes.io/component app.kubernetes.io/part-of app.kubernetes.io/version app.kubernetes.io/managed-by Note: Once there will no more supported versions that added those labels to the namespace it will be safe to remove cleanUpNamespaceRelationLables. https://bugzilla.redhat.com/show_bug.cgi?id=2033385 Signed-off-by: Or Shoval <oshoval@redhat.com> Co-authored-by: Or Shoval <oshoval@redhat.com>
Signed-off-by: GitHub <noreply@github.com> Co-authored-by: qinqon <qinqon@users.noreply.github.com>
* bump nmstate to v0.64.11 Signed-off-by: CNAO Bump Bot <noreply@github.com> * automation: Adapt to ginkgo v2 Signed-off-by: Quique Llorente <ellorent@redhat.com> Co-authored-by: CNAO Bump Bot <noreply@github.com> Co-authored-by: Quique Llorente <ellorent@redhat.com>
Signed-off-by: GitHub <noreply@github.com> Co-authored-by: qinqon <qinqon@users.noreply.github.com>
This release holds fixes to CNAO ovs-cni teir1 ci Signed-off-by: Ram Lavi <ralavi@redhat.com>
* golang, Bump to 1.17 Signed-off-by: Ram Lavi <ralavi@redhat.com> * gen-k8s, Run make gen-k8s Signed-off-by: Ram Lavi <ralavi@redhat.com>
* controller: Adapt to controller-runtime version The new controller-runtime expect a context.Context on the Reconcile interface. This change add that to the controllers. Signed-off-by: Quique Llorente <ellorent@redhat.com> * deps: Adapt to v1.y.z version of operator-sdk The operator-sdk 1.y.z introduced backward imcompatible changes: - The "test" package no longer exists and we have to use testenv - The operator-sdk generate does not exist and we have to sue controller-gen - The generated code is different and we have to adapt to it. Signed-off-by: Quique Llorente <ellorent@redhat.com> gen: Use controller-gen to generate k8s code Signed-off-by: Quique Llorente <ellorent@redhat.com> * vendor, Bump k8s vendors to 0.23.1 This also requires bumping controller-runtime to v0.11.1 and pinning k8s.io/kube-openapi as well. Signed-off-by: Ram Lavi <ralavi@redhat.com> Co-authored-by: Quique Llorente <ellorent@redhat.com>
Signed-off-by: GitHub <noreply@github.com> Co-authored-by: RamLavi <RamLavi@users.noreply.github.com>
* cluster, bump KUBEVIRTCI_TAG to 2203222209-7c38b02 In order to use centos-stream8 and also use the correct kubevirt-provider From this tag there is no longer need to install networkManager since it is already installed Signed-off-by: Ram Lavi <ralavi@redhat.com> * cluster, bump KUBEVIRT_PROVIDER to k8s-1.23 k8s-1.23 is the version run with this branch. Signed-off-by: Ram Lavi <ralavi@redhat.com> * test: Remove upgraded test for < 0.52 versions The release-0.65 branch is using k8s 1.23 and from 1.22 apiextensions.k8s.io/v1beta1 and others are deprecated. This change remove the tests for CNAO versions not compatible with that. Signed-off-by: Quique Llorente <ellorent@redhat.com> Co-authored-by: Quique Llorente <ellorent@redhat.com>
Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
HCO will reconcile and see that the NAC status is degraded and in turn set it's status upgradeable to false. That will block upgrade until user installs KNO Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
Signed-off-by: CNAO Bump Bot <noreply@github.com> Co-authored-by: CNAO Bump Bot <noreply@github.com>
Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
Signed-off-by: CNAO Bump Bot <noreply@github.com> Co-authored-by: CNAO Bump Bot <noreply@github.com>
…ubevirt#1334) Value of Upgradeable/Available condition propagates to HCO operator. Since we want to only express we want to block an upgrade when nmstate is enabled in CNAO, it's more accurate to only set Upgradeable condition instead of setting Availabe condition to False. With this change, HCO will set Upgradeable condition to False, but will remain Available, which describes the situation better. Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
Signed-off-by: CNAO Bump Bot <noreply@github.com> Co-authored-by: CNAO Bump Bot <noreply@github.com>
* e2e/monitoring, Add monitring e2e test lane (kubevirt#1250) Adding a new e2e test module and lane for monitoring. Signed-off-by: Ram Lavi <ralavi@redhat.com> * Add alert to notify of nmstate removal kubernetes-nmstate is removed in the next CNAO version. This change adds an alert that notifies users who have knmstate deployed with CNAO, and point them to runbook, that explains that standalone kubernetes-nmstate operator should be installed. Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com> * e2e, monitoring: test CnaoNmstateMigration alert Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com> * go mod vendor Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com> * Add priority: high label to alert CnaoNmstateMigration Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com> Co-authored-by: RamLavi <ralavi@redhat.com>
When CNAO hands over knmstate deployment to KNO, NMstate remains in networkAddonsConfig spec. For that, we need to check whether KNO is present to make sure the Not Upgradeable condition is removed, when KNO is installed. Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
When using Openshift, in case cluster-reader ClusterRole exists, Users of cluster-readers group should be able to access k8s nmstate crds, such as nns, nncp and nnce. Add a ClusterRole that allows it in case cluster-reader exists. Signed-off-by: Or Shoval <oshoval@redhat.com>
Signed-off-by: Petr Horáček <phoracek@redhat.com>
Signed-off-by: CNAO Bump Bot <noreply@github.com> Co-authored-by: CNAO Bump Bot <noreply@github.com>
* nmstate: Avoid syncing NMState CR when already exists and KNO is running This change adds a flag to clusterInfo, which informs whether NMState CR exists. If it exists and KNO is installed, CNAO doesn't re-apply the NMState CR to sync it's configuration accordingly to NAC. Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com> * Add knmstate API Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com> * e2e, test nmstate CR is not updated after it's created Signed-off-by: Radim Hrazdil <rhrazdil@redhat.com>
Signed-off-by: Enrique Llorente <ellorent@redhat.com>
Thanks for your pull request. Before we can look at it, you'll need to add a 'DCO signoff' to your commits. 📝 Please follow instructions in the contributing guide to update your commits with the DCO Full details of the Developer Certificate of Origin can be found at developercertificate.org. The list of commits missing DCO signoff:
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. |
@qinqon: PR needs rebase. 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. |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
What this PR does / why we need it:
Cherry-pick from #1401