[ovirt-devel] [ACTION REQUIRED] new dependency -- ovirt-js-dependencies (replaces PatternFly)

Greg Sheremeta gshereme at redhat.com
Tue Feb 14 18:59:52 UTC 2017


Does anyone have any other input or objections about anything *other than*
which repos we're using?

Best wishes,
Greg


On Tue, Feb 14, 2017 at 7:11 AM, Sandro Bonazzola <sbonazzo at redhat.com>
wrote:

>
>
> On Tue, Feb 14, 2017 at 10:14 AM, Martin Perina <mperina at redhat.com>
> wrote:
>
>>
>>
>> On Tue, Feb 14, 2017 at 9:54 AM, Barak Korren <bkorren at redhat.com> wrote:
>>
>>> On 14 February 2017 at 09:53, Martin Perina <mperina at redhat.com> wrote:
>>> >
>>> >
>>> > On Mon, Feb 13, 2017 at 9:59 PM, Greg Sheremeta <gshereme at redhat.com>
>>> wrote:
>>> >>
>>> >> On Mon, Feb 13, 2017 at 3:55 PM, Eyal Edri <eedri at redhat.com> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Mon, Feb 13, 2017 at 10:34 PM, Martin Perina <mperina at redhat.com>
>>> >>> wrote:
>>> >>>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> why is this package not contained also in ovirt-master-snapshot
>>> >>>> repository [6]? Most of developers are using ovirt-master-snapshot,
>>> because
>>> >>>> this is the official repository for oVirt depelopers as mentioned
>>> in [7] and
>>> >>>> [8]. AFAIK there was not yet any official announcement that every
>>> developer
>>> >>>> should switch from ovirt-master-snapshot to ovirt-tested-master ...
>>> >>>
>>> >>>
>>> >>> I think we should make it official then for master, we've hit too
>>> many
>>> >>> issues in the past weeks due to this repository, that I don't want
>>> to see
>>> >>> new projects added to it.
>>> >
>>> >
>>> > You've run into issues, because
>>> >
>>> > migration to the "new" system is not well prepared. I'm still a bit
>>> angry
>>> > that you have forced me to migrate all ovirt-engine-extensions*
>>> projects
>>> > into standard CI (which took me more than 2 days) by breaking existing
>>> build
>>> > jobs which worked fine until recent changes. And I had to do fast that
>>> > otherwise I won't be able to provide new build for upstream 4.1.0
>>> async and
>>> > 4.1.1 builds ...
>>>
>>> I think there is some miss-communication here. The old '-snapshot'
>>> repo is causing issues because of the way it is built. We want people
>>> to move away from it. However, we did not intend to force anyone to
>>> move. It is still there, and the nightly jobs still update it with all
>>> the packages that have been in it so far.
>>>
>>>   http://jenkins.ovirt.org/job/ovirt_master_publish-rpms_nightly/
>>>
>>> I really don't see how any of the recent changes forced you to change
>>> your project's own jobs, but it is a good thing if you did.
>>>
>>
>> ​Well, build jobs just started to fail and I discussed with either you or
>> Gil and you just told me that why it's failing and the only solution is to
>> move std CI.
>> But let's leave this behind us, ​
>>
>> ​ovirt-engine-extensions* move to std-CI ​and build jobs are working now
>> correctly ...
>>
>>
>>> > So I don't have an issue to move from ovirt-master-snapshot repos to
>>> > ovirt-tested-master repos, but please do that properly:
>>> >
>>> >   1. Announce on mailing lists that every developer should switch at
>>> least a
>>> > week before the change
>>>
>>> We were planning, since all repos currently exist side-by-side we saw
>>> no rush to do that.
>>>
>>> >   2. Update all developer related documentation about this change
>>>
>>> Well, I'm not sure where such things are documented currently, but
>>> that is a reasonable request.
>>>
>>> >   2. Maintain both repos for a week and only after that turn off
>>> > ovirt-master-snapshots repos
>>>
>>> We did not turn it off yet. It is still there. The only thing that
>>> happened is that the new JS projects, that were never in that repo to
>>> begin with, chose to forgo publishing to it.
>>>
>>
>> ​Sure, that's why I asked to put this ovirt-js-dependencies package into
>> ovirt-master-snapshot repo, which all developers are using ...
>>>>
>>
>>>
>>> > Exported artifacts is not enough, please provide
>>> ovirt-release-tested-master
>>> > RPM which will include all necessary repositories same way as we
>>> currenlty
>>> > have in ovirt-release-master
>>>
>>> There is some subtle distinction here that needs to be well understood.
>>> Some repos are build to emulate an oVirt release, and all or most of
>>> the packages are collected in them. The 'tested' repo is an example of
>>> such a repo. For such repos it makes sense to create a
>>> '*-release-*.rpm'.
>>>
>>
>> ​So ovirt-release-master RPM will add repositories with needed packages
>> to develop engine/VDSM. For engine development it means you have following
>> packages​:
>>
>> ovirt-master-snapshot:
>>     otopi
>>     ovirt-host-deploy
>>     ovirt-setup-lib
>>     ovirt-vmconsole
>>
>> ovirt-master-snapshot-static
>>     ovirt-engine-wildfly
>>     ovirt-engine-wildfly-overlay
>>
>> ovirt-master-patternfly1-noarch-epel
>>     patternfly1
>>
>> There are other packages, but those are needed only when developing
>> relevant parts of engine (for example "unboundid-ldapsdk" needed for
>> ovirt-engine-extension-aaa-ldap).
>>
>> So in my opinion if you want to switch to ovirt-latest-tested repo, we
>> need to have available also those dependencies, that's why I think it's
>> required to have ovirt-release-latest-tested RPM which will install all
>> repos to develop and even install/run master oVirt from RPM.
>>
>>
> Make sense to me. Current effort anyway it to reach a point where nothing
> need to be changes, just the content of ovirt-master-snapshot will be
> genertared from latest-tested instead of from jenkins master nightly
> publisher job.
>
>
>
>>
>>> The 'exported-artifacts' repos are meant to allow "upstream" or
>>> "build-dependency" projects to have their own release stream that is
>>> independent of oVirt's release stream. For such repos it makes little
>>> sense to keep a '*-release-*.rpm'.
>>>
>>> All projects that have a 'build-articats job now have an
>>> 'exported-artifacts' repo and their packages are submitted to OST so
>>> eventually also end up in the 'tested' repo. It is left to the
>>> consuming projects to pick which repo to use depending on how tightly
>>> are they coupled with consumed packages.
>>>
>>>
>>> --
>>> Barak Korren
>>> bkorren at redhat.com
>>> RHCE, RHCi, RHV-DevOps Team
>>> https://ifireball.wordpress.com/
>>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170214/12f7c3e1/attachment.html>


More information about the Devel mailing list