[INTPAK-189] Improve Apex proposed-change-distro upgrade logic Created: 29/Jun/18  Updated: 29/Jun/18

Status: Open
Project: integration-packaging
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Low
Reporter: Daniel Farrell Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to INTPAK-20 Gerrit keyword to build distro and pa... Open
relates to INTPAK-161 Create scratch pkg repos Closed

 Description   

There's work ongoing to use OPNFV Apex images in ODL CI as a quick way to stand up real OpenStack+ODL deployments. The logic needs to build an ODL distro from a proposed change, then update the version of ODL in the Apex images with the proposed distro. The logic currently does this, but in a hacky way. Per trozet:

Well I solved it, but in a hacky way. When the job goes to update odl, it brings down docker container. It then extracts the tar.gz netvirt distro into /opt. Then it copies a systemd unit file, creates the odl user and group. I use puppet tags to avoid puppet-opendaylight trying to install the ODL repo or RPM. You can see it all here:
https://gerrit.opnfv.org/gerrit/#/c/59017/5/odl-pipeline/lib/odl_reinstaller/odl_reinstaller.py

Not the greatest code in the world, but it works for now. If we had an RPM built with the patch set that would be much cleaner, but if you don't have time then don't worry about it for now.

So eventually should consider improving that upgrade logic with RPM-native upgrades. This relates to INTPAK-20 and INTPAK-161.


Generated at Wed Feb 07 20:03:51 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.