[ovirt-devel] [ACTION REQUIRED] new dependency -- ovirt-js-dependencies (replaces PatternFly)
Greg Sheremeta
gshereme at redhat.com
Fri Feb 17 16:44:52 UTC 2017
Oh, also, if you're on Fedora 23 or older, you'll need to manually install
the rpm, since we only have builds for f24+
$ sudo dnf install
http://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc24/x86_64/ovirt-js-dependencies-0.0.3-2.fc24.x86_64.rpm
Best wishes,
Greg
On Wed, Feb 15, 2017 at 10:11 AM, Greg Sheremeta <gshereme at redhat.com>
wrote:
> This was merged, and the RPM is in the snapshots repository. Therefore,
> you do not need to add the tested-master repo as I mentioned in the
> original thread. (See https://gerrit.ovirt.org/#/c/72352/ for more info
> on that, if you're interested.)
>
> Please don't hesitate to contact me if you see anything strange with the
> UI.
>
> Thanks,
> Greg
>
>
> On Tue, Feb 14, 2017 at 1:59 PM, Greg Sheremeta <gshereme at redhat.com>
> wrote:
>
>> 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
>>
>
>
>
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gshereme at redhat.com
>
--
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/20170217/d62b8645/attachment.html>
More information about the Devel
mailing list