Adding a non-voting adoption test job

[jpodivin]

No description provided.

[softwarefactory-project-zuul]

Zuul encountered a syntax error while parsing its configuration in the
repo openstack-k8s-operators/dataplane-operator on branch main. The
error was:

expected str for dictionary value @ data['github-check']['jobs'][1]['voting']

The error appears in the following project stanza:

project:
name: openstack-k8s-operators/dataplane-operator
github-check:
jobs:
- dataplane-operator-docs-preview
- name: data-plane-adoption-github-rdo-centos-9-crc-single-node
voting: false
templates:
- podified-multinode-edpm-baremetal-pipeline

in "openstack-k8s-operators/dataplane-operator/zuul.d/projects.yaml@main", line 2, column 3

[softwarefactory-project-zuul]

Zuul encountered a syntax error while parsing its configuration in the
repo openstack-k8s-operators/dataplane-operator on branch main. The
error was:

'str' object does not support item assignment

The error appears in the following project stanza:

project:
name: openstack-k8s-operators/dataplane-operator
github-check:
jobs:
- dataplane-operator-docs-preview
- name: data-plane-adoption-github-rdo-centos-9-crc-single-node
voting: 'false'
templates:
- podified-multinode-edpm-baremetal-pipeline

in "openstack-k8s-operators/dataplane-operator/zuul.d/projects.yaml@main", line 2, column 3

[softwarefactory-project-zuul]

Zuul encountered a syntax error while parsing its configuration in the
repo openstack-k8s-operators/dataplane-operator on branch main. The
error was:

extra keys not allowed @ data['github-check']['jobs'][1]['job']['name']

The error appears in the following project stanza:

project:
name: openstack-k8s-operators/dataplane-operator
github-check:
jobs:
- dataplane-operator-docs-preview
- job:
name: data-plane-adoption-github-rdo-centos-9-crc-single-node
voting: false
templates:
- podified-multinode-edpm-baremetal-pipeline

in "openstack-k8s-operators/dataplane-operator/zuul.d/projects.yaml@main", line 2, column 3

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://review.rdoproject.org/zuul/buildset/bf20720379fd45f9afcbf5f6a0470092

✔️ openstack-k8s-operators-content-provider SUCCESS in 1h 13m 01s
❌ podified-multinode-edpm-deployment-crc RETRY_LIMIT in 4s
✔️ cifmw-crc-podified-edpm-baremetal SUCCESS in 54m 53s
✔️ data-plane-adoption-github-rdo-centos-9-crc-single-node SUCCESS in 1h 28m 33s (non-voting)

[jpodivin]

recheck - retry limit

[slagle]

Even with the job as non-voting, I don't think this should be in github-check. My opinion is that I don't want this job running on every PR, it ought to be on demand triggered, or periodic.

[jpodivin]

Even with the job as non-voting, I don't think this should be in github-check. My opinion is that I don't want this job running on every PR, it ought to be on demand triggered, or periodic.

Adoption process is going to be one of the first experiences our customers have with our new Openstack. Apart from obvious complexity involved, it's for this reason that we should expend effort to test this process soon, and often.

The job does take time, but not substantially more than those we already have. The resources to run it are available, and even if it turned out to be unstable, which shouldn't happen, the non-voting nature will prevent it from blocking us.

[slagle]

Even with the job as non-voting, I don't think this should be in github-check. My opinion is that I don't want this job running on every PR, it ought to be on demand triggered, or periodic.

Adoption process is going to be one of the first experiences our customers have with our new Openstack. Apart from obvious complexity involved, it's for this reason that we should expend effort to test this process soon, and often.

Agreed, but it doesn't need to be part of testing on all PRs.

The job does take time, but not substantially more than those we already have. The resources to run it are available, and even if it turned out to be unstable, which shouldn't happen, the non-voting nature will prevent it from blocking us.

We should be pushing more of our CI testing to be post-merge, not pre-merge. Are there specific gaps in kuttl or EnvTest that we can close that would provide similar benefit for pre-merge testing?

Hypothetically we could cobble together something. But I would question a value of such a solution. It's easier to maintain 1 job then 2 jobs doing the same thing in a different way. And there is no guarantee it would be faster, or offer any tangible benefit over running it in RDO.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jpodivin
Once this PR has been reviewed and has the lgtm label, please ask for approval from slagle. For more information see the Kubernetes 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:

• OWNERS

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

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://review.rdoproject.org/zuul/buildset/e1c81d8ce3e64321ba9f95b0327bd4b3

✔️ openstack-k8s-operators-content-provider SUCCESS in 1h 30m 04s
✔️ podified-multinode-edpm-deployment-crc SUCCESS in 1h 03m 50s
❌ cifmw-crc-podified-edpm-baremetal FAILURE in 1h 01m 21s
✔️ data-plane-adoption-github-rdo-centos-9-extracted-crc SUCCESS in 1h 54m 44s (non-voting)

[jpodivin]

/retest-required