MCO-1634: Enhance SNO stability for MachineConfigNode tests #29667
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@isabella-janssen: This pull request references MCO-1634 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.19.0" version, but no target version was set. In response to this: 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 openshift-eng/jira-lifecycle-plugin repository. |
|
Skipping CI for Draft Pull Request. |
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: isabella-janssen 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 |
|
/test e2e-aws-ovn-single-node-techpreview-serial |
|
@isabella-janssen: The following test 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-sigs/prow repository. I understand the commands that are listed here. |
…ests Value was previously hardcoded. Can be replaced now since openshift/api has been bumped and has the `configv1.ClusterVersionCapabilityOperatorLifecycleManagerV1` constant. Signed-off-by: Anik Bhattacharjee <[email protected]>
Updated synthetic tests
When IPsec tests configuring certificates into libreswan nss db for north south traffic via a machine config, it's rebooting worker nodes by default which still makes one of the following monitor test to fail. 4 unexpected clusteroperator state transitions during e2e test run. These did not match any known exceptions, so they cause this test-case to fail: Jan 15 19:44:18.575 E clusteroperator/kube-storage-version-migrator condition/Available reason/KubeStorageVersionMigrator_Deploying status/False KubeStorageVersionMigratorAvailable: Waiting for Deployment Jan 15 19:44:18.575 - 5s E clusteroperator/kube-storage-version-migrator condition/Available reason/KubeStorageVersionMigrator_Deploying status/False KubeStorageVersionMigratorAvailable: Waiting for Deployment Jan 15 20:06:29.820 E clusteroperator/kube-storage-version-migrator condition/Available reason/KubeStorageVersionMigrator_Deploying status/False KubeStorageVersionMigratorAvailable: Waiting for Deployment Jan 15 20:06:29.820 - 1s E clusteroperator/kube-storage-version-migrator condition/Available reason/KubeStorageVersionMigrator_Deploying status/False KubeStorageVersionMigratorAvailable: Waiting for Deployment 2 unwelcome but acceptable clusteroperator state transitions during e2e test run. These should not happen, but because they are tied to exceptions, the fact that they did happen is not sufficient to cause this test-case to fail: Jan 15 19:44:24.518 W clusteroperator/kube-storage-version-migrator condition/Available reason/AsExpected status/True All is well (exception: Available=True is the happy case) Jan 15 20:06:31.725 W clusteroperator/kube-storage-version-migrator condition/Available reason/AsExpected status/True All is well (exception: Available=True is the happy case) Actually it is not required to reboot the nodes just for configuring certs on the nss db. Hence adding nod edisruption machine configuration policy so that nodes are not rebooted while deploying certificates on the worker nodes. Signed-off-by: Periyasamy Palanisamy <[email protected]>
When IPsec mode are changed across tests within IPsec test suite, it causes reboot of ovnkube-node daemonset pods, It's expected workload traffic would fail temporarily until pods are settle down after IPsec is properly configured in every node's OVN and OvS across the cluster. So we should not test ipsec mode change in the ipsec test suite and instead for every ipsec mode, there should be one CI lane, then in the test corresponding configuration and traffic must be tested. So this commit removes everything related to IPsec mode changes and having a single test which can be run from Full and External IPsec mode CI lanes. Signed-off-by: Periyasamy Palanisamy <[email protected]>
… to docs.redhat.com after docs migration docs.openshift.com got moved to docs.redhat.com and our egress firewall/egressnetworkpolicy tests were using that fqdn to curl and test for egress firewall functionality. With the DNS name no longer resolving, these tests need to be updated to the docs.redhat.com server instead.
This is the binding which we will use on 4.18. In later releases we expect passt to replace it, but, its shortcomings (unable to preserve TCP connections during live migration) make it a bad candidate for the binding of the primary network attachment. Signed-off-by: Miguel Duarte Barroso <[email protected]>
The Unmarshal function uses strict decoding by default. This means that the target object must define all fields present in the CBOR data. Otherwise, it returns an unknown field error. This patch fixes that by using a intermediary map[string]any.
The timelines-chart seems to have changed at this unpkg location, if you load that in a browser and search for the TimelinesChart object we use, it's no longer there, though it does load some js. The github repo for the actual project https://github.com/vasturiano/timelines-chart recommends this new url and I've confirmed this works by downloading an html intervals file and editing it.
…la-janssen/openshift-origin into mcn-enhance-sno-stability
openshift-merge-robot
added
the
needs-rebase
|
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-sigs/prow repository. |
|
/close |
|
@isabella-janssen: Closed this PR. In response to this:
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-sigs/prow repository. |
No description provided.