broken master: removal of release in spec requirements
Hi, In https://gerrit.ovirt.org/#/c/62672 we removed the release from vdsm* requirements. Although it sounds reasonable and quite safe, it was not. In development env it causes mixup of versions when upgrading. "yum install vdsm" will eventually cause this mixup as vdsm won't require the newer vdsm-python I think this change should be reverted and the solution should be in the build process. Newer release is equal to higher version, requirement should include the release number. so for example, 4.18.7-1 was shipped and for ppc we built 4.18.7-2 so 4.18.7-2 is newer. can't see how this can be different. e.g for the bug: =================================================================================================================================================================================================================== Package Arch Version Repository Size =================================================================================================================================================================================================================== Removing: vdsm x86_64 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 2.7 M vdsm-api noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 325 k vdsm-cli noarch 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 342 k vdsm-hook-vmfex-dev noarch 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 21 k vdsm-jsonrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 81 k vdsm-python noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 2.4 M vdsm-xmlrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 109 k vdsm-yajsonrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 95 k Problem. -- *Yaniv Bronhaim.*
If this is true, then the ioprocess change [1] also needs to be reverted? [1] https://gerrit.ovirt.org/#/c/62464/1 On Sun, Aug 28, 2016 at 3:17 PM, Yaniv Bronheim <ybronhei@redhat.com> wrote:
Hi,
In https://gerrit.ovirt.org/#/c/62672 we removed the release from vdsm* requirements. Although it sounds reasonable and quite safe, it was not. In development env it causes mixup of versions when upgrading.
"yum install vdsm" will eventually cause this mixup as vdsm won't require the newer vdsm-python
I think this change should be reverted and the solution should be in the build process. Newer release is equal to higher version, requirement should include the release number. so for example, 4.18.7-1 was shipped and for ppc we built 4.18.7-2 so 4.18.7-2 is newer. can't see how this can be different.
e.g for the bug:
============================================================ ============================================================ ============================================================ =============================== Package Arch Version Repository Size ============================================================ ============================================================ ============================================================ =============================== Removing: vdsm x86_64 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 2.7 M vdsm-api noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 325 k vdsm-cli noarch 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 342 k vdsm-hook-vmfex-dev noarch 4.18.999-457.gitcde215c.el7.centos @ovirt-master-snapshot 21 k vdsm-jsonrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 81 k vdsm-python noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 2.4 M vdsm-xmlrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 109 k vdsm-yajsonrpc noarch 4.18.999-342.git40c3bbb.el7.centos @ovirt-master-snapshot 95 k
Problem.
-- *Yaniv Bronhaim.*
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
On Sun, Aug 28, 2016 at 3:25 PM, Eyal Edri <eedri@redhat.com> wrote:
If this is true, then the ioprocess change [1] also needs to be reverted?
In the python-ioprocess case, the real dependency is on ioprocess apis, which must *never* change in backward incompatible way in minor versions, so depending on ioprocess for the same version is safe. Nir
----- Original Message -----
From: "Yaniv Bronheim" <ybronhei@redhat.com> To: "devel" <devel@ovirt.org>, "Nir Soffer" <nsoffer@redhat.com>, "Francesco Romani" <fromani@redhat.com> Cc: "Yevgeny Zaspitsky" <yzaspits@redhat.com> Sent: Sunday, August 28, 2016 2:17:56 PM Subject: broken master: removal of release in spec requirements
Hi,
In https://gerrit.ovirt.org/#/c/62672 we removed the release from vdsm* requirements. Although it sounds reasonable and quite safe, it was not. In development env it causes mixup of versions when upgrading.
"yum install vdsm" will eventually cause this mixup as vdsm won't require the newer vdsm-python
I see, and I'm ok with the revert. I can take care, because who messed up should also clean up :) That said, I still wonder if this applies only to development snapshots (I think yes, customers shouldn't seen this), and, if so, how we could handle this differently without a revert.
I think this change should be reverted and the solution should be in the build process. Newer release is equal to higher version, requirement should include the release number. so for example, 4.18.7-1 was shipped and for ppc we built 4.18.7-2 so 4.18.7-2 is newer. can't see how this can be different.
I still think this is not the best way :\ Bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
On Sun, Aug 28, 2016 at 3:17 PM, Yaniv Bronheim <ybronhei@redhat.com> wrote:
Hi,
In https://gerrit.ovirt.org/#/c/62672 we removed the release from vdsm* requirements. Although it sounds reasonable and quite safe, it was not. In development env it causes mixup of versions when upgrading.
I think this change was unneeded, as vdsm builds for different architectures use the *same* release: name-major.minor.bugfix-release.offset.githash Unlike other packages using: name-major.minor.bugfix-release.timestamp.githash So I don't see why this patch was needed. Additionally, vdsm sub packages are tightly coupled, and using a package from different commit is *not* supported, as internal apis may always change. So we should revert this patch. Nir
----- Original Message -----
From: "Nir Soffer" <nsoffer@redhat.com> To: "Yaniv Bronheim" <ybronhei@redhat.com> Cc: "devel" <devel@ovirt.org>, "Francesco Romani" <fromani@redhat.com>, "Yevgeny Zaspitsky" <yzaspits@redhat.com> Sent: Monday, August 29, 2016 12:14:49 PM Subject: Re: broken master: removal of release in spec requirements
On Sun, Aug 28, 2016 at 3:17 PM, Yaniv Bronheim <ybronhei@redhat.com> wrote:
Hi,
In https://gerrit.ovirt.org/#/c/62672 we removed the release from vdsm* requirements. Although it sounds reasonable and quite safe, it was not. In development env it causes mixup of versions when upgrading.
I think this change was unneeded, as vdsm builds for different architectures use the *same* release:
name-major.minor.bugfix-release.offset.githash
Unlike other packages using:
name-major.minor.bugfix-release.timestamp.githash
So I don't see why this patch was needed.
Additionally, vdsm sub packages are tightly coupled, and using a package from different commit is *not* supported, as internal apis may always change.
So we should revert this patch.
Alright, here it is: https://gerrit.ovirt.org/#/c/62922/1 bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
participants (4)
-
Eyal Edri -
Francesco Romani -
Nir Soffer -
Yaniv Bronheim