Hi there, Leap 15.0 includes Ceph Mimic (13.x). The version included in the distribution is an (unstable) development version 13.0.2. But there are newer (stable) versions available, so the question is: will the newer version make it into the Leap 15.0 update repo? And generally how does that process work?
Newer version of products in general do not make it as replacements in a current Leap version. Only security (and some really needed recommended) updates come as patches and they are normally implemented by back-porting them into the version that is in that Leap version and not as a complete new version.
Leap is released as a stable product. That means also that no newer versions are introduced during it’s life time because those newer version may also contain changes that involve adaption of the user (a changed GUI e.g. where buttons, etc. are on different places).
The newer version may make it into the next version of Leap when it is available in time before that version is frozen and it passes the integrated tests of that new openSUSE Leap version.
Those who like to have newer versions all the time use Tumbleweed.
It could be that people make a newer version of a product available on the OBS and you can of course install and use them (search on https://software.opensuse.org/search ). But they are not “official”.
The version included in the distribution is an (unstable) development version 13.0.2. But there are newer (stable) versions available, so the question is: will the newer version make it into the Leap 15.0 update repo?
although I don’t have too many details available about the process itself I can upgrade the packages to 13.2.1.
If I add this to my repos
zypper ar https://download.opensuse.org/repositories/filesystems:/ceph:/mimic/openSUSE_Leap_15.0/ Mimic
I can install 13.2.1:
leap15:~ # zypper lr -d | grep ceph
2 | Mimic | Mimic | Ja | (r ) Ja | Nein | 99 | rpm-md | https://download.opensuse.org/repositories/filesystems:/ceph:/mimic/openSUSE_Leap_15.0/ |
leap15:~ # zypper dup -r 2
...]
Problem: Problem mit installiertem Paket ceph-common-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: Problem mit installiertem Paket libcephfs2-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: Problem mit installiertem Paket liboath0-2.6.2-lp150.1.1.x86_64
Problem: Problem mit installiertem Paket librados2-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: Problem mit installiertem Paket libradosstriper1-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: Problem mit installiertem Paket librbd1-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: Problem mit installiertem Paket librgw2-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: Problem mit installiertem Paket oath-toolkit-xml-2.6.2-lp150.1.1.noarch
Problem: Problem mit installiertem Paket python3-cephfs-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: Problem mit installiertem Paket python3-rados-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: Problem mit installiertem Paket python3-rbd-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: Problem mit installiertem Paket python3-rgw-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: Problem mit installiertem Paket ceph-common-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Lösung 1: ceph-common-13.2.1.427+g6cd01d4dd2-lp150.2.1.x86_64 installieren (mit Anbieterwechsel)
openSUSE --> obs://build.opensuse.org/filesystems
Lösung 2: veraltetes ceph-common-13.0.2.1874+ge31585919b-lp150.1.2.x86_64 beibehalten
If you want to use the packages from a different repository you’ll have to run a zypper dup (dist-upgrade). Be very careful with that! If you only want to upgrade packages from a specific repo, provide the respective repo with the option “-r <REPO>”.
The new packages are usually added to the official update repos if they are considered safe to upgrade so you don’t break your system with an update. Just recently we had an issue with our Ceph cluster, the fix was first available in non-official repos. Then after a couple of weeks the fix was released into the official update repo, they have to wait for confirmation that the update doesn’t break anything.
That’s not how it works. Yes, you can force install of a package from a repo, but zypper will always try to use the packages from the distribution repos. But, the proper way to deal with this situation is to use
This way zypper will prevail packages from the Mimic repo over the ones in the distribution repos, and the next ‘zypper up’ will work according to the new setup.
Thanks for the clarification, I thought by providing the “-r ” switch the result would be the same. What exactly is the difference between “–from” and “–repo”?
EDIT:
I just found the answer in the man page of zypper:
-r, --repo alias|name|#|URI
Work only with the repository specified by the alias, name, number or URI. This option can be used multiple times.
Using --repo is discouraged as it currently hides unmentioned repositories from the resolver, leading to inexpertly decisions. In the future --repo will become an alias for --from.
This suggests to me that you’ve added your repo incorrectly,
And, AFAIK you shouldn’t have to do a “zypper dup – from *alt_repo *”
Because the version of CEPH in your new repo has a more current version, an ordinary “zypper up” should have automatically pulled in the latest available in all your configured repos.
Try this…
Remove your existing ceph repo…
Then add the repo without specifying the repodata file as follows
zypper ar -f https://download.opensuse.org/repositories/filesystems:/ceph:/mimic/openSUSE_Leap_15.0/ ceph:mimic_LEAP_15
Followed by an update
zypper up
I’d expect you should then pick up your updated version of ceph.
I don’t think a vendor change will likely be necessary, but if it’s required you’ll be presented with that decision.
From your reply: you’re not re. the quoted part here. I missed that change. But, if invoked only during install, wouldn’t some additional option be needed on updating? I do know a ‘zypper dup --from’ ( or ‘zypper dup --repo’ as I know now ) keeps the system stick to packages from that repo, also on ‘zypper up’. I would never use a plain ‘zypper dup’ on Leap, except when upgrading to the next Leap version.
Thanks for the info, btw.
# Installed Ceph from oss repo
leap15:~ # zypper se -s ceph-common
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
S | Name | Typ | Version | Arch | Repository
---+-----------------------+-------+-----------------------------------+--------+-----------------------
v | ceph-common | Paket | 13.2.1.427+g6cd01d4dd2-lp150.2.1 | x86_64 | Mimic
i+ | ceph-common | Paket | 13.0.2.1874+ge31585919b-lp150.1.2 | x86_64 | openSUSE-Leap-15.0-Oss
| ceph-common-debuginfo | Paket | 13.2.1.427+g6cd01d4dd2-lp150.2.1 | x86_64 | Mimic
# No ceph-related updates available
leap15:~ # zypper lu | grep ceph
leap15:~ #
# But a dist-upgrade would work
leap15:~ # zypper dup -r 1
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
12 Problems:
Problem: problem with installed package ceph-common-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: problem with installed package libcephfs2-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: problem with installed package liboath0-2.6.2-lp150.1.1.x86_64
Problem: problem with installed package librados2-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: problem with installed package libradosstriper1-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: problem with installed package librbd1-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: problem with installed package librgw2-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: problem with installed package oath-toolkit-xml-2.6.2-lp150.1.1.noarch
Problem: problem with installed package python3-cephfs-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: problem with installed package python3-rados-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: problem with installed package python3-rbd-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: problem with installed package python3-rgw-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Problem: problem with installed package ceph-common-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Solution 1: install ceph-common-13.2.1.427+g6cd01d4dd2-lp150.2.1.x86_64 (with vendor change)
openSUSE --> obs://build.opensuse.org/filesystems
Solution 2: keep obsolete ceph-common-13.0.2.1874+ge31585919b-lp150.1.2.x86_64
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c):
...]
leap15:~ # zypper se -s ceph-common
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+-----------------------+---------+-----------------------------------+--------+-----------------------
i+ | ceph-common | package | 13.2.1.427+g6cd01d4dd2-lp150.2.1 | x86_64 | Mimic
v | ceph-common | package | 13.0.2.1874+ge31585919b-lp150.1.2 | x86_64 | openSUSE-Leap-15.0-Oss
Interesting.
I wonder if you had actually tried to run the update instead of simply listing updates whether you would have been presented with the option to do the vendor change which is what I would have expected.
As Knurpht describes,
The difference is that when you do a “zypper dup -r” or “zypper dup --from” you’re committing to packages only from that repo whereas if a “zypper up” works and what is used, then you’d always update to the most recent version no matter what repo the most recent exists in.
This forum is so awesome! Thanks heaps for the explanations!
Because these machines are on Leap 15.0, not Tumbleweed, I only want to use dup to upgrade to the next version of Leap, and the only package I actually need to update is ceph.
So, piecing together the various suggestions, I’m going with
zypper ar -f https://download.opensuse.org/repositories/filesystems:/ceph:/mimic/openSUSE_Leap_15.0/ ceph:mimic_LEAP_15
Followed by
# zypper up ceph
Loading repository data...
Reading installed packages...
There is an update candidate for 'ceph', but it is from a different vendor. Use 'zypper install ceph-13.2.2.86+g62b49f06c4-lp150.1.1.x86_64' to install this candidate.
Resolving package dependencies...
Nothing to do.
Reading this back, the reason I thought adding the repository didn’t work, is because
zypper list-updates
didn’t include the newer ceph version. Which is probably because a vendor change would be necessary, but to a user it seems as if there simply aren’t any updates available which is clearly false. You only find out there are updates by actually trying to install them.
I wonder if zypper should not have the “–allow-vendor-change” flag on list-updates too?
If a package is installed, zypper up will no do any vendor-change.
But if you want to change a package to another repo, you can install it with -force:
zypper in -f foo
This will install the package from the repo with the highest priority or the package with the highest version.
Or switch all installed packages to another repo, if avaible, with
zypper dup --from #Uri|Name|Alias
I would also do not use zypper dup without --from, only after installing a new openSUSE Version and adding after that the Packman Repo (Thats the first thing I do after installing a new openSUSE).
Interesting.
I wonder if you had actually tried to run the update instead of simply listing updates whether you would have been presented with the option to do the vendor change which is what I would have expected.
Running zypper up results in
leap15:~ # zypper up
Loading repository data...
Reading installed packages...
The following 12 package updates will NOT be installed:
ceph-common libcephfs2 liboath0 librados2 libradosstriper1 librbd1 librgw2 oath-toolkit-xml python3-cephfs python3-rados python3-rbd python3-rgw
...]
because they would require a vendor change.
If no ceph package is installed yet and the Mimic repo is enabled you’re presented with the vendor change option:
leap15:~ # zypper in ceph-common
Loading repository data...
Reading installed packages...
Resolving package dependencies...
Problem: ceph-common-13.2.2.86+g62b49f06c4-lp150.1.1.x86_64 requires librados2 = 13.2.2.86+g62b49f06c4-lp150.1.1, but this requirement cannot be provided
not installable providers: librados2-13.2.2.86+g62b49f06c4-lp150.1.1.x86_64[Mimic]
Solution 1: install librados2-13.2.2.86+g62b49f06c4-lp150.1.1.x86_64 (with vendor change)
openSUSE --> obs://build.opensuse.org/filesystems
Solution 2: do not install ceph-common-13.2.2.86+g62b49f06c4-lp150.1.1.x86_64
Solution 3: break ceph-common-13.2.2.86+g62b49f06c4-lp150.1.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c):
So both
zypper dist-upgrade --repo <REPO>
and
zypper in ceph=<VERSION>
are valid update paths here.
To point it out again because it’s of significant importance: be very very careful with dist-upgrade without the “–repo” switch!!