Bug 1459343
Summary: | bigswitch component is downgraded after yum update on overcloud components | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | bigswitch <rhosp-bugs-internal> |
Component: | python-networking-bigswitch | Assignee: | RHOS Maint <rhos-maint> |
Status: | CLOSED NOTABUG | QA Contact: | Ofer Blaut <oblaut> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 9.0 (Mitaka) | CC: | aschultz, jschluet, lhh, mburns, rhosp-bugs-internal |
Target Milestone: | --- | ||
Target Release: | --- | ||
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: | 2017-06-09 17:27:31 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
bigswitch
2017-06-06 21:20:08 UTC
Can you tell me where you got the python-networking-bigswitch 8.40.8 package? As far as I can tell we haven't released one yet. If it's your own package, make sure the epoch is set to 2 in the packaging. This should prevent it from being 'upgraded' to the 2015.3.8 version. Hi Alex, the 8.40.8 package is packaged into overcloud.qcow2 image using virt-customize before deploying RHOSP 9. Who created the package? The issue is that the packages needs to be created with epoch > 1 to ensure it's not updated to the old one which is what you are experiencing. This is not an issue with our existing available packages as we do not currently ship any 8.40.x package. I know one is currently being tested but has yet to be released. Hi Alex, Thanks for the info, that helps. The spec file here [1] is what creates the new packages. I see that epoch hasn't changed. Just curious - does the epoch change for all Openstack packages? Since the major version number change from 2015.x.x (year based version number) to 8.x.x (simply release based) was done for all services, including the plugins. Also, changing epoch should not require any other changes to the spec file, right? I should probably open the PR for it and discuss it there (spec file has a copy in one of RDOs repos, which actually triggers the update). [1] https://github.com/openstack/networking-bigswitch/blob/stable/mitaka/rhel/python-networking-bigswitch.spec Our packaging uses this as it's upstream version: https://github.com/rdo-packages/networking-bigswitch-distgit/blob/rpm-master/python-networking-bigswitch.spec which as you can see has the epoch set to 2. We had to do this for the year based version switch for many projects. The upstream changed these version numbers around the mitaka timeframe so that is why this is needed. That makes sense. From the same repo, I see that Epoch is set to 2 for master, Ocata and Newton, but not for Mitaka[1]. Probably that's why on upgrade from Liberty to Mitaka, the yum update pulls incorrect version. I'll open a PR to update that. Thanks again Alex! [1] https://github.com/rdo-packages/networking-bigswitch-distgit/blob/rpm-mitaka/python-networking-bigswitch.spec#L9 Opened a code review to update it: https://review.rdoproject.org/r/#/c/7045/ Please take a look :) Hi Mike, Alex, I have a follow-up query - since Mitaka is EOL, is it possible to not update networking-bigswitch plugin by removing it from the repo config files? When upgrading from RHOSP 9 to RHOSP 10, there is a yum update that happens on overcloud and it gets stuck - since overcloud is RHOSP 9 and it gets the liberty package, which stalls the neutron-server process due to version mismatch. Mitaka is EOL at the RDO level. OSP 9 is still supported. We've already bumped epoch for this package to 2 in OSP 9 (it's in a package that has not yet been shipped, but is pending) Ah, I misunderstood EOL as no further updates. If the epoch change goes out in the next update for RHOSP 9, that works perfectly well. Thanks Mike! |