Red Hat Bugzilla – Bug 1477894
Fedora Atomic Host logical volume renamed from docker-pool
Last modified: 2017-08-03 10:26:21 EDT
Description of problem:
Scripts that used lvresize to expand the docker volume on Fedora Atomic Host 25 no longer work on the Fedora Atomic Host 26.
It is routine to have to expand the volume in an Atomic Host qcow2 image to the actual disk size. One uses lvresize to do this. Scripts that did this in an automated fashion used to use the command:
lvresize atomicos/docker-pool -l+100%FREE
Version-Release number of selected component (if applicable):
# rpm -q container-storage-setup
Steps to Reproduce:
1. lvresize atomicos/docker-pool -l+100%FREE
Logical volume docker-pool not found in volume group atomicos.
Size of logical volume atomicos/docker-pool changed from 1,91 GiB (488 extents) to 3,34 GiB (855 extents).
Logical volume atomicos/docker-pool successfully resized.
A workaround is to upgrade all scripts that were used to deploy an Atomic Host to deal with both the old and new names.
This bug was found by the Cockpit integration tests.
Colin, I'm CCing you as this is an example of an Atomic Host upgrade bug that is related to a single stream, and future tests related to upgrading within that stream.
I don't believe this is an 'upgrade bug', though. If you have a system that previously was installed with f25 and you rebase to f26 you don't have a problem.
This is more of a compatibility bug where scripts that used to work on f25 atomic host first bringup now fail. However, switching from devicemapper to overlay was something that we decided to do and did communicate out. What could we have done better?
> A workaround is to upgrade all scripts that were used to deploy an Atomic Host to deal with both the old and new names.
Fedora 25 atomic host is no longer really encouraged to be used so that might be a waste of time???
Yep, this is absolutely the kind of thing we need to smooth over for a single stream experience. Related to this, we also still have the issue that the default LV name differs between ISO and cloud images.
In this particular case though, I think the changes in F27 in particular for unified pool fix a lot of the problem long term; in the kind of "casual use" scenario you don't need to think about LVM. Experienced sysadmins for large installs are going to be able to cope with this type of thing relatively easily.
Is this going to be a problem with the Openshift Ansible scripts and RHEL Atomic Host? That was my worry when I highlighted it.
If RHEL Atomic Host in 7.4.x or 7.5.x is going to pull a similar LV rename, then someone really should double check the popular Ansible scripts to see whether it hoses them or not.
Ideally Fedora Atomic's own automated tests would catch this. That's why we want:
But in this case Cockpit integration testing highlighted this as a possible issue.
Of course we hope to soon remove any container runtime, other then runc off of atomic host.
(In reply to Stef Walter from comment #5)
> Is this going to be a problem with the Openshift Ansible scripts and RHEL
> Atomic Host? That was my worry when I highlighted it.
I have been running the installer on every release we do in Fedora atomic host. Have worked through any issues we've had, but we have had no issues with storage that I know of.
> If RHEL Atomic Host in 7.4.x or 7.5.x is going to pull a similar LV rename,
> then someone really should double check the popular Ansible scripts to see
> whether it hoses them or not.
I'm not sure about that