fc27 job failing on missing vmconsole
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/ is failing since yesterday on Error: Problem 1: conflicting requests - nothing provides ovirt-vmconsole >= 1.0.0-0 needed by vdsm-4.20.11-7.git4a7f18434.fc27.x86_64 after already passing in the past. Can this be solved on ovirt-vmconsole side, or should we disable fc27 (again)? Dan.
On 01/05/2018 08:16 AM, Dan Kenigsberg wrote:
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/ is failing since yesterday on
Error: Problem 1: conflicting requests - nothing provides ovirt-vmconsole >= 1.0.0-0 needed by vdsm-4.20.11-7.git4a7f18434.fc27.x86_64
after already passing in the past.
Can this be solved on ovirt-vmconsole side, or should we disable fc27 (again)?
Speaking as maintainer of ovirt-console, it is a good chance to review what's the status of ovirt-vmconsole, and how we can improve things for the current state and for the future. ovirt-vmconsole is pretty stable codewise and featurewise (and, I'd say, bugwise), in the last 12+ months I hardly gathered material for another minor release (would be 1.0.5), which is not planned yet, as further proof that the codebase is stable. Most of time, the only thing needed is to ship the existing packages for a new distro release. It seldom may be needed a simple rebuild. I must say I'm not aware of how the current issue was solved for fc26, IIRC some manual intervation was applied along the lines above. Can we automate this step somehow? Bests, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh
On Fri, Jan 5, 2018 at 10:20 AM, Francesco Romani <fromani@redhat.com> wrote:
On 01/05/2018 08:16 AM, Dan Kenigsberg wrote:
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/ is failing since yesterday on
Error: Problem 1: conflicting requests - nothing provides ovirt-vmconsole >= 1.0.0-0 needed by vdsm-4.20.11-7.git4a7f18434.fc27.x86_64
after already passing in the past.
Can this be solved on ovirt-vmconsole side, or should we disable fc27 (again)?
Speaking as maintainer of ovirt-console, it is a good chance to review what's the status of ovirt-vmconsole, and how we can improve things for the current state and for the future.
ovirt-vmconsole is pretty stable codewise and featurewise (and, I'd say, bugwise), in the last 12+ months I hardly gathered material for another minor release (would be 1.0.5), which is not planned yet, as further proof that the codebase is stable.
Most of time, the only thing needed is to ship the existing packages for a new distro release. It seldom may be needed a simple rebuild.
I must say I'm not aware of how the current issue was solved for fc26, IIRC some manual intervation was applied along the lines above. Can we automate this step somehow?
Barak and Sandro can surely help with regards to fc27, and may have ideas on how to automate this to future releases.
On 5 January 2018 at 11:14, Dan Kenigsberg <danken@redhat.com> wrote:
On Fri, Jan 5, 2018 at 10:20 AM, Francesco Romani <fromani@redhat.com> wrote:
On 01/05/2018 08:16 AM, Dan Kenigsberg wrote:
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/ is failing since yesterday on
Error: Problem 1: conflicting requests - nothing provides ovirt-vmconsole >= 1.0.0-0 needed by vdsm-4.20.11-7.git4a7f18434.fc27.x86_64
after already passing in the past.
Can this be solved on ovirt-vmconsole side, or should we disable fc27 (again)?
Speaking as maintainer of ovirt-console, it is a good chance to review what's the status of ovirt-vmconsole, and how we can improve things for the current state and for the future.
ovirt-vmconsole is pretty stable codewise and featurewise (and, I'd say, bugwise), in the last 12+ months I hardly gathered material for another minor release (would be 1.0.5), which is not planned yet, as further proof that the codebase is stable.
Most of time, the only thing needed is to ship the existing packages for a new distro release. It seldom may be needed a simple rebuild.
I must say I'm not aware of how the current issue was solved for fc26, IIRC some manual intervation was applied along the lines above. Can we automate this step somehow?
Barak and Sandro can surely help with regards to fc27, and may have ideas on how to automate this to future releases.
I looked into what happened there. It seems that Sandro added fc27 jobs a few weeks ago ago, and he also took the time to trigger the jobs manually to get an FC27 build. The issue is that this is not enough to get a build to properly go through the automated test and release processes, The CI system is build to respond on code changes. For most projects that is enough because new patches are merged frequently and as new jobs are added, patches show up soon after and trigger them. The root cause for this issue is that the set of platforms a project targets is currently maintained separately from the project's source code, so adding a new target platform is not always manifest in a code change to the project. We're working on resolving this by making the set of target platform be specified in the project's own source code. This would eventually mean that adding a new target platfrom will always require a patch to the project. For now, I've emulated a merge event on the latest patch to ovirt-vmconsole. This will cause the fc27 build (as well as others) to get recreated and pushed through the change-queue. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On 07.01.2018 11:11, Barak Korren wrote: [...]
I looked into what happened there.
It seems that Sandro added fc27 jobs a few weeks ago ago, and he also took the time to trigger the jobs manually to get an FC27 build.
The issue is that this is not enough to get a build to properly go through the automated test and release processes,
The CI system is build to respond on code changes. For most projects that is enough because new patches are merged frequently and as new jobs are added, patches show up soon after and trigger them.
The root cause for this issue is that the set of platforms a project targets is currently maintained separately from the project's source code, so adding a new target platform is not always manifest in a code change to the project. We're working on resolving this by making the set of target platform be specified in the project's own source code. This would eventually mean that adding a new target platfrom will always require a patch to the project.
For now, I've emulated a merge event on the latest patch to ovirt-vmconsole. This will cause the fc27 build (as well as others) to get recreated and pushed through the change-queue.
I think we face a similar problem for the s390x builds of ovirt-host. Looks like the last changes to ovirt-host have been done before the s390x fc27 jobs have been merged, so there are no s390x RPMS in the repository. Could you or someone else trigger a full ovirt-host build? -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski
On 11 January 2018 at 14:55, Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> wrote:
On 07.01.2018 11:11, Barak Korren wrote: [...]
I looked into what happened there.
It seems that Sandro added fc27 jobs a few weeks ago ago, and he also took the time to trigger the jobs manually to get an FC27 build.
The issue is that this is not enough to get a build to properly go through the automated test and release processes,
The CI system is build to respond on code changes. For most projects that is enough because new patches are merged frequently and as new jobs are added, patches show up soon after and trigger them.
The root cause for this issue is that the set of platforms a project targets is currently maintained separately from the project's source code, so adding a new target platform is not always manifest in a code change to the project. We're working on resolving this by making the set of target platform be specified in the project's own source code. This would eventually mean that adding a new target platfrom will always require a patch to the project.
For now, I've emulated a merge event on the latest patch to ovirt-vmconsole. This will cause the fc27 build (as well as others) to get recreated and pushed through the change-queue.
I think we face a similar problem for the s390x builds of ovirt-host. Looks like the last changes to ovirt-host have been done before the s390x fc27 jobs have been merged, so there are no s390x RPMS in the repository. Could you or someone else trigger a full ovirt-host build?
Done: http://jenkins.ovirt.org/job/ovirt-host_master_build-artifacts-fc27-s390x/1/ The oVirt master change-queue is currently processing through some regressions, so it might take a while for this to reach the repos. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On 14.01.2018 19:01, Barak Korren wrote: [..]
Could you or someone else trigger a full ovirt-host build?
Done: http://jenkins.ovirt.org/job/ovirt-host_master_build-artifacts-fc27-s390x/1/
The oVirt master change-queue is currently processing through some regressions, so it might take a while for this to reach the repos.
Excellent, thanks Barak. -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski
participants (4)
-
Barak Korren -
Dan Kenigsberg -
Francesco Romani -
Viktor Mihajlovski