[ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2

Sun Jan 28 07:39:33 UTC 2018

On 28 January 2018 at 09:32, Yedidyah Bar David <didi at redhat.com> wrote:

> On Fri, Jan 26, 2018 at 3:45 PM, Sandro Bonazzola <sbonazzo at redhat.com>
> wrote:
>
>>
>>
>> 2018-01-24 11:11 GMT+01:00 Martin Sivak <msivak at redhat.com>:
>>
>>> Hi,
>>>
>>> > You`re asking a bigger question here - Who decides which distros/archs
>>> > each project targets. The CI system currently places the burden of
>>> > this decision on the shoulders of individual maintainers. We could
>>> > have done things differently and placed the decision solely in the
>>> > hands of the integration team.
>>>
>>> Actually, I believe it should be a global decision of the project
>>> leadership. But I believe the word global to be important here. We
>>> should decide together and then a common version to platform map
>>> should be prepared by the integration team.
>>>
>>> Single projects could still add additional overrides if needed though.
>>>
>>> > The reason to placing the power (and responsibility) in the hands of
>>> > maintainers we simple - we wanted to reduce the chances of having
>>> > maintainers be surprised.
>>>
>>> This actually means we get surprised and confused indeed. Please note
>>> that nobody really told us that Fedora bits are not going to be
>>> released anymore (see 4.2 release notes [1]) and whether we should
>>> update the job specifications or not.
>>>
>>
>> Integration team reported to the developers community that Fedora support
>> was broken starting with Fedora 26 back on August 2017[1].
>> We also reported during the beta process that oVirt 4.2 would have not
>> supported Fedora to user list  in November 2017 [2] since nobody fixed
>> Fedora support in the meanwhile.
>> No request or direction about what to do with Jenkins fedora jobs has
>> been issued since we (integration team at least) want Fedora support back
>> in 4.3 but since we don't have yet a schedule for 4.3 we don't know yet
>> which fedora version we'll target. In integration team we are now slowly
>> enabling jobs on master for fc27 and fcraw (rawhide).
>>
>> [1] https://lists.ovirt.org/pipermail/devel/2017-August/030990.html
>> [2] https://lists.ovirt.org/pipermail/users/2017-November/085006.html
>>
>
> I'd like to clarify my own understanding re what should be done with
> jenkins jobs.
>
> 1. You can still, and are very welcome to, have and maintain fedora
> builds/jobs for your projects.
>
> 2. Not officially publishing builds does not mean you can't build them, and
> if you do, they are still published in the -snapshot repos, so users that
> do
> want them, can have them.
>
> 3. If building for fedora will make the job(s) for your projects fail
> constantly,
> either because you have bugs there, or because you rely on some
> infrastructure
> packages (otopi, ovirt-setup-lib, etc) to work on fedora (and with
> python3),
> then it probably does not make sense to build yet for fedora - this will
> simply
> add noise.
>

This will cause more then just noise - if a project fails to build on any
platform it explicitly targets - builds from all plaforms are blocked and
do not get released to the '*-snapshot' repo. If you tell CI you want to
support platfrom X, it holds you to it...

I'm a little frustrated that this OT discussion derailed the original
discussion of getting proper testing for 4.2.

>
> 4. If OTOH your project is independent, and works just fine on fedora, you
> are
> more than welcome to build (and then publish in -snapshot). Doing this will
> very likely make the eventual transition to "fedora is supported" much
> smoother.
>
> 5. This is really a per-project decision, so unless we start having
> cross-project
> discussions about this, you should decide for yourself. Just keep in mind
> that
> eventually we'll have EL8, which is very likely to be more similar to
> current
> fedora than to current EL7, so better prepare... (saying this also mainly
> to
> myself!).
>
> Best regards,
>
>
>>
>>
>>
>>
>>>
>>> > Suppose we made it so that target distros
>>> > change globally for everyone - you would have had patches failing CI
>>> > at arbitrary times as new target distros or architectures were
>>> > added...
>>>
>>> Right. But we have something very similar now: spreadsheets with lists
>>> of packages that are missing from a new version compose. I do not see
>>> too much difference actually..
>>>
>>> > Personally I prefer that decisions remain distributed
>>>
>>> I agree with who decides things (all of us). But the decision needs to
>>> be documented. Do we have any (easy to find) list of expected
>>> platforms for given a release?
>>>
>>> The decision then might be compiled into a file we could include and
>>> stay current without manual edits.
>>>
>>> [1] https://www.ovirt.org/release/4.2.0/#no-fedora-support
>>>
>>> Martin
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>>
>> Red Hat EMEA <https://www.redhat.com/>
>> <https://red.ht/sig>
>> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Didi
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>

-- 
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20180128/6c2cb8c7/attachment-0001.html>