[ovirt-devel] fc27 job failing on missing vmconsole

[Barak Korren]

On 5 January 2018 at 11:14, Dan Kenigsberg <danken at redhat.com> wrote:
> On Fri, Jan 5, 2018 at 10:20 AM, Francesco Romani <fromani at 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