4:09 p.m.
Hi all,
The repo files for ovirt-4.0 seem to have overlapping packages from (el7 vs
centos.el7 naming).
resources.ovirt.org: ovirt-4.0
and
mirror.centos.org/centos/7/virt/x86_64/ovirt-4.0/: centos-ovirt40-release
for example
vdsm-4.18.15.3-1.el7.centos.x86_64.rpm
vs
vdsm-4.18.15.3-1.el7.x86_64.rpm
Which one should "win"? We need this for auditing purposes.
Thanks.
--
Richard Chan
1:25 a.m.
On Thu, Dec 29, 2016 at 11:09 PM, Richard Chan <richard(a)treeboxsolutions.com
wrote:
Hi all,
The repo files for ovirt-4.0 seem to have overlapping packages from (el7
vs centos.el7 naming).
resources.ovirt.org: ovirt-4.0
and
mirror.centos.org/centos/7/virt/x86_64/ovirt-4.0/: centos-ovirt40-release
for example
vdsm-4.18.15.3-1.el7.centos.x86_64.rpm
vs
vdsm-4.18.15.3-1.el7.x86_64.rpm
Which one should "win"? We need this for auditing purposes.
Thanks.
Hi,
when a new oVirt release is announced the oVirt project releases source
code developed and tested during the release cycle.
For convenience, the oVirt release engineering team builds rpms for Fedora,
Red Hat Enterprise Linux and similar.
oVirt is not a Linux distribution.
Once oVirt release is available, the CentOS VIrtualization SIG packages the
oVirt Virtualization Host related packages and make them available on
CentOS mirrors.
CentOS Linux is a Linux distribution.
So, if you need auditing on CentOS only, you should rely on CentOS
repositories and not enabling oVirt repositories on Virtualization Hosts.
On the manager side, oVirt engine is not yet packaged by CentOS
Virtualization SIG being it almost impossible to package without accessing
maven central during the build which is not allowed by packaging policies.
So, for the oVirt Engine host, you've no choice but use oVrit repositories
or build rpms yourself.
The fact you see overlapping versions in oVirt repo and CentOS
Virtualization SIG repositories is due to the fact the two repositories are
independent. You can use either the oVIrt one (built by oVirt release
engineering) or the CentOS one (built by CentOS Virt SIG).
--
Richard Chan
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
8:41 a.m.
"The fact you see overlapping versions in oVirt repo and CentOS
Virtualization SIG repositories is due to the fact the two repositories are
independent. You can use either the oVIrt one (built by oVirt release
engineering) or the CentOS one (built by CentOS Virt SIG)."
We are actually ok with using resources.ovirt.org packages but the CentOS
VIrtualization SIG repo was enabled by ovirt-release40-4.0.5-2.noarch
itself:
/etc/yum.repos.d/ovirt-4.0-dependencies.repo:
[centos-ovirt40-release]
name=CentOS-7 - oVirt 4.0
baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-4.0/
gpgcheck=0
enabled=1
This stanza does not use priority= or includepkgs= so is it deterministic
that vdsm comes from resources.ovirt.org?
1. When I did a test run of "yum install vdsm":
vdsm-* packages were pulled from ovirt-4.0 (yay!)
but
python-*
safelease
ioprocess
openvswitch
ovirt-imageio-*
came from centos-ovirt40-release.
2. To be deterministic, i.e., force vdsm* from ovirt-4.0 insteaad of
accidentally getting from CentOS SIG, I am considering (similar to the
epel repo stanza)
[centos-ovirt40-release]
name=CentOS-7 - oVirt 4.0
baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-4.0/
includepkgs=python-* safelease ioprocess openvswitch ovirt-imageio-*
## or exclude=vdsm*
gpgcheck=0
enabled=1
What do you think about this tightening? Thanks.
Richard Chan
10:09 a.m.
On Mon, Jan 2, 2017 at 3:41 PM, Richard Chan <richard(a)treeboxsolutions.com>
wrote:
"The fact you see overlapping versions in oVirt repo and CentOS
Virtualization SIG repositories is due to the fact the two repositories are
independent. You can use either the oVIrt one (built by oVirt release
engineering) or the CentOS one (built by CentOS Virt SIG)."
We are actually ok with using resources.ovirt.org packages but the CentOS
VIrtualization SIG repo was enabled by ovirt-release40-4.0.5-2.noarch
itself:
/etc/yum.repos.d/ovirt-4.0-dependencies.repo:
[centos-ovirt40-release]
name=CentOS-7 - oVirt 4.0
baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-4.0/
gpgcheck=0
enabled=1
This stanza does not use priority= or includepkgs= so is it deterministic
that vdsm comes from resources.ovirt.org?
1. When I did a test run of "yum install vdsm":
vdsm-* packages were pulled from ovirt-4.0 (yay!)
but
python-*
safelease
ioprocess
openvswitch
ovirt-imageio-*
came from centos-ovirt40-release.
2. To be deterministic, i.e., force vdsm* from ovirt-4.0 insteaad of
accidentally getting from CentOS SIG, I am considering (similar to the
epel repo stanza)
[centos-ovirt40-release]
name=CentOS-7 - oVirt 4.0
baseurl=http://mirror.centos.org/centos/7/virt/$basearch/ovirt-4.0/
includepkgs=python-* safelease ioprocess openvswitch ovirt-imageio-*
## or exclude=vdsm*
gpgcheck=0
enabled=1
What do you think about this tightening? Thanks.
I think exclude vdsm* should be enough for your purpose.
> Richard Chan
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
2911
days inactive
2915
days old
3 comments
2 participants
participants (2)
-
Richard Chan -
Sandro Bonazzola