Bug 1359377
Summary: | can't yum update to new swift packages | ||
---|---|---|---|
Product: | [Community] RDO | Reporter: | James Slagle <jslagle> |
Component: | openstack-swift | Assignee: | Alan Pevec <apevec> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | nlevinki <nlevinki> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | trunk | CC: | derekh, hguemar, jslagle, karlthered, srevivo, zaitcev |
Target Milestone: | --- | ||
Target Release: | trunk | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-10-03 13:26:17 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
James Slagle
2016-07-23 12:30:13 UTC
I don't have a record of what delorean repo I started with (it was blown away when I updated the repo files), but it ought to be the one that contains openstack-swift-2.9.1-0.20160721045247.45080a5.el7.centos.noarch I think the problem might be that we use both a delorean pinned repo (called delorean in the yum output) and the latest delorean (called delorean-current), and there is no openstack-swift in delorean-current? if I yum erase openstack-swift I can work around this issue I suspect it's me, see https://review.rdoproject.org/r/1575 However, I have actually tested the upgrade path and the spec includes Obsoletes: openstack-swift just to deal with this. It's possible that the condition in it was insufficient. It only obsoletes up to a certain version, 2.9.0, and the above packages are 2.9.1. I'll add Haikel to cc:, so he can tell me how to write Obsoletes: properly. There's now Provides: openstack-swift in python-swift subpackage, but Obsoletes: openstack-swift < 2.9.0 works only for Mitaka upgrades. Upgrades on trunk were not supported by design, but we could make it work by removing < 2.9.0. Haikel? http://review.rdoproject.org/r/1724 Support upgrades from trunk to trunk packages In RDO Trunk master builds since openstack-swift-2.9.1-0.20160724221722.574a666.el7 No please, don't test upgrades from DLRN to DLRN packages, this is a very bad idea. 1. DLRN versioning generation code is more robust but 100% safe as it doesn't check previously generated versions. So potentially, a newer package can have a lower NVR and we'd have to introduce epoch which are a pain to maintain *forever* 2. We use DLRN in order to co-develop packaging and installers in parallel of upstream code. Sometimes we introduces workarounds not to block CI, or without proper reviewing. Supporting upgrades means that we'd have to support these too. For instance, we need flexibility to change/test packages split or not (especially with new packages), upgrades would mean that we can't anymore. Alternative plan: * test upgrades from released packages to DLRN packages. * Add non-voting gates on upgrades in RDO *against* released packages. * Ship M2 and M3 stable packages (Newton M3 will be shipped in CentOS Newton testing) --- AFAIK, we can make do for that by Obsoletes: openstack-swift < %{version}-%{release} You're not supposed to have newer package than the latest so it will effectively (if you do, then we're outside what RPM can do). Unversioned Obsoletes in a released package, means that we cannot reintroduce that subpackage later if needed. > Unversioned Obsoletes in a released package, means that we cannot reintroduce that subpackage later if needed. But in this particular case, this will not happen. I know never say never, but once we approved openstack-swift change in https://review.rdoproject.org/r/1575 we are not going to change out minds, right? In the immediate future, nope, unless puppet-swift kicks in. |