TRT-2388: Migrate 4.21 periodics openshift cluster network operator

[neisw]

Working through some automation to ensure periodics are configured as documented in configuration-for-periodic-jobs. It is possible there are outliers that specifically need to be in main / master. Opening for review.

[openshift-ci-robot]

@neisw: This pull request explicitly references no jira issue.

In response to this:

Working through some automation to ensure periodics are configured as documented in configuration-for-periodic-jobs. It is possible there are outliers that specifically need to be in main / master. Opening for review.

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.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: neisw
Once this PR has been reviewed and has the lgtm label, please assign jacobtanenbaum for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• ci-operator/config/openshift/cluster-network-operator/OWNERS
• ci-operator/jobs/openshift/cluster-network-operator/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

[REHEARSALNOTIFIER]
@neisw: the pj-rehearse plugin accommodates running rehearsal tests for the changes in this PR. Expand 'Interacting with pj-rehearse' for usage details. The following rehearsable tests have been affected by this change:

Test name	Repo	Type	Reason
periodic-ci-openshift-cluster-network-operator-release-4.21-periodics-e2e-aws-ovn-subnet-configs	N/A	periodic	Periodic changed
periodic-ci-openshift-cluster-network-operator-release-4.21-periodics-e2e-aws-ovn-clusternetwork-cidr-expansion	N/A	periodic	Periodic changed

Prior to this PR being merged, you will need to either run and acknowledge or opt to skip these rehearsals.

Interacting with pj-rehearse

Comment: /pj-rehearse to run up to 5 rehearsals
Comment: /pj-rehearse skip to opt-out of rehearsals
Comment: /pj-rehearse {test-name}, with each test separated by a space, to run one or more specific rehearsals
Comment: /pj-rehearse more to run up to 10 rehearsals
Comment: /pj-rehearse max to run up to 25 rehearsals
Comment: /pj-rehearse auto-ack to run up to 5 rehearsals, and add the rehearsals-ack label on success
Comment: /pj-rehearse list to get an up-to-date list of affected jobs
Comment: /pj-rehearse abort to abort all active rehearsals
Comment: /pj-rehearse network-access-allowed to allow rehearsals of tests that have the restrict_network_access field set to false. This must be executed by an openshift org member who is not the PR author

Once you are satisfied with the results of the rehearsals, comment: /pj-rehearse ack to unblock merge. When the rehearsals-ack label is present on your PR, merge will no longer be blocked by rehearsals.
If you would like the rehearsals-ack label removed, comment: /pj-rehearse reject to re-block merging.

[neisw]

/pj-rehearse

[openshift-ci-robot]

@neisw: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel.

[openshift-ci]

@neisw: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/rehearse/periodic-ci-openshift-cluster-network-operator-release-4.21-periodics-e2e-aws-ovn-subnet-configs	23448a0	link	unknown	/pj-rehearse periodic-ci-openshift-cluster-network-operator-release-4.21-periodics-e2e-aws-ovn-subnet-configs

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.

[openshift-ci-robot]

@neisw: This pull request references TRT-2388 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.21.0" version, but no target version was set.

In response to this:

Working through some automation to ensure periodics are configured as documented in configuration-for-periodic-jobs. It is possible there are outliers that specifically need to be in main / master. Opening for review.

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.

[neisw]

@jcaamano @tssurya - we are looking to make sure periodics are lined up with releases so we can analyze the signal properly. Let me know if this update looks right to you or you feel it belongs in master.

[jcaamano]

@neisw honestly I would like to understand the difference. Isn't 4.21 and master the same thing now, so both definitions here would be in sync and equal?

[jcaamano]

@neisw honestly I would like to understand the difference. Isn't 4.21 and master the same thing now, so both definitions here would be in sync and equal?

also, don't we need the master definitions to be able to use things like /payload-job-with-prs? For example, I tried to use it here and it didn't work and I was thinking it was because the periodic is defined in 4.21 but not in master.

[neisw]

@jcaamano - There is no difference in the code being tested. But for the tooling we use like Sippy && Component Readiness there is a difference between main/master and 4.21. We require a specific OCP release to collect and analyze the data. Currently we are running both main/master and 4.21 jobs which effectively duplicates job runs and doubles the frequency.

That said there have been branching issues with the periodic variant configuration not getting promoted at branch time. Part of the what led to finding these master configuration is looking for those gaps to try to get that issue resolved.

don't we need the master definitions to be able to use things like /payload-job-with-prs

I don't believe so. You are looking to run the 4.21 version job, not the master. Also the jobs for the current dev branch have been disabled previously so that only the master jobs were runnning. This we turned off while we work to resolve the missing periodic configuration branching step but will likely be the case again soon.

No rush on this PR, it was something I found while investigating how we can fix the gap with periodic variant config branching. If you want to hold off for now you can.

[jcaamano]

I don't believe so. You are looking to run the 4.21 version job, not the master.

Ok because I tried that and it didn't work for me.
openshift/origin#30456 (comment)

Also the jobs for the current dev branch have been disabled previously so that only the master jobs were runnning. This we turned off while we work to resolve the missing periodic configuration branching step but will likely be the case again soon.

Not sure if I am understanding this backwards. Are you saying dev release branch jobs are currently disabled?

[jcaamano]

Wouldn't we have to do the same for all releases? I see that for older releases, 4.20, 4.19,..., we are also not using the periodics variant for these same jobs.

[neisw]

Not sure if I am understanding this backwards. Are you saying dev release branch jobs are currently disabled?

Previously active dev release branch jobs were disabled and only the main/master job were running, this was considered a cost saving measure within DPTP. This was turned off to allow the current active dev release jobs to run as well as master/main in an attempt to address the missing periodic variant configured jobs after branching. That didn't address the issue however and I expect that change to be reverted when we get all of this settled.

For previous releases you don't have to backport these changes as those configuration and jobs exists and are not duplicating anything.

I did see your payload job failures. I don't believe the failure is because it is defined in a periodic variant config. I have my own payload-job running based on a job configured from openshift-machine-config-operator-release-4.21__periodics.yaml it seems to be running fine at the moment. There is something else going on with the job you are trying to test and the payload-job command but I don't believe it is because of were the job is configured.