Naïvely assumes package upgrade command is "upgrade"; breaks package_upgrade on SLES

Bug #1556100 reported by Florian Haas on 2016-03-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Medium
Unassigned

Bug Description

cc_package_update_upgrade_install.py assumes that for a package upgrade, it can simply append the literal "upgrade" to the package_command in order to effect a system package upgrade.

On SLES, this causes zypper to be invoked as "zypper --non-interactive upgrade"; but zypper doesn't have an "upgrade" option. It's called "update" instead, and for this to work, zypper would have to be called as "zypper --non-interactive update".

In other words, given a cloud-config of

# cloud-config
package_update: true
package_upgrade: true

... the former will succeed and the latter will fail, which is not only broken functionality but also highly unintuitive.

Suggestion: define a per-distro method named upgrade_packages, akin to update_package_sources, and invoke that method rather than naïvely appending "upgrade" to whatever the package_command has been determined to be.

Florian Haas (fghaas) on 2016-03-11
summary: - Naïvely assumes package upgrade command is "upgrade"; breaks updates on
- SLES
+ Naïvely assumes package upgrade command is "upgrade"; breaks
+ package_upgrade on SLES
Scott Moser (smoser) wrote :

Florian, thanks for the bug.

Changed in cloud-init:
importance: Undecided → Low
status: New → Confirmed
importance: Low → Medium
Florian Haas (fghaas) wrote :

For what it's worth: as I've heard in the interim, SUSE seems to ship their own fork of cloud-init in SLES and OpenSUSE, so I'm not sure how much sense it makes to fix this upstream.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers