Description of problem: this is horrible. we have gone back 20 years in time. no lvm?! the sweat and tears of untold programmers and sysadmin are thrown away for an illogical reason. how many users want static sized VMs? how many users suddenly find their static sized vm is suddenly too small and unable to expand? bring back LVM! put it in the cloud images! Version-Release number of selected component (if applicable): How reproducible: everytime Steps to Reproduce: 1.run a fedora cloud image 2.run some lvm command 3.weep! Actual results: Expected results: Additional info:
Just to be clear, do you want LTD for the root filesystem, or just for it to be available to use for additional disks you may attach? For the former, online resizing of the filesystem is supported if you boot with a larger disk (and I think this should even happen by default during boot). For the latter, yum/dof install lvm...
Please excuse obvious typos in the previous comment. Stupid autocorrect. :-)
lvm for the root filesystem yes just like a default minimum install of a server. in cloud hosting, sometimes the only person or team who can access the console to take the server down to init 1 to do the filesystem conversion is the hosting company. (nb: not all hosting companies give console access) and normally there would be a cost associated with such a change. and yes i have seen ppl who have 1 huge lvm spanning several TB disks
Generally, the cloud-based approach is to reprovision a new image with a larger disk. This is part of the "cattle vs. pets" mentality (see e.g. http://www.theregister.co.uk/2013/03/18/servers_pets_or_cattle_cern/) -- if you have a system which needs individual system administration and management of disk, it's probably a pet -- and not in the target of the cloud image. (Probably a better bet to install Fedora Server in the VM.) That said, I think you're missing part of Andy's point. You don't need to take the filesystem down to init 1 to do any conversion. Just resize the disk and reboot, and cloud-init can take care of resizing the root partition to fill the space. And, footnote #2, note that the Fedora Atomic image _does_ use LVM, with LVM-provisioned space for running Docker containers.
reprovision a new image with a larger disk? i am sorry to say that you sound far from the operations side. i doubt any customer would entertain such a suggestion from a cloud provider. the cloud currently is an extension of current physical world best practices: in the real world a physical machine needs more disk space, storage is allocated from the array and added to the lvm. with an instance the same applies. but the fedora cloud image is purposely handicapped
Mohammed, your statement that "the cloud currently is an extension of current physical world best practices" is pretty far off the mark in my opinion, but even if that were true, it's never been a best practice to grow your root filesystem as large as you are describing. The filesystem hierarchy is well defined so that subtrees such as /var/log, /srv, /opt, /home, and others can be separated onto other partitions (using LVM if desired) and grown separately as needed. That is a very simple solution to your stated problem. Is there a reason that this best practice is not sufficient?
i appreciate you guys listening to me, and i understand where you are coming from and aiming for (i think) but not all customers will have the expertise, ability or money to have "cattle". i have used cloud images at around 4 or 5 providers and most of the time, these cloud providers target customers who have 1 to 100 servers. and as far as i know i have only heard of 2 cloud customers who have setup puppet servers to manage their automation. but even then, not all cloud providers will open up their api, and if they do open up their api not all will provide full api access (if available) that allows a customer to "refresh"/"reprovision" servers. may i say that aiming to have cattle servers is a great target and yet we still are at the pet stage: most customers/users require lvm. having said the above. my personal experience is that we get all sorts of ppl using cloud images. we cant cater for just one kind of user. so what if some user wants to have 1 tb / partition? if the user knows how to handle it that way great. after all, open source is about choice. lets leave the choice in the equation. thanks for listening
Mohammed, here is the problem we face: we have one set of users who want everything about the cloud image to be just as it always has been, and another set who want it "optimized" for cloud-specific use-cases. These are conflicting goals, and in the end, the freedom and choice that every user has is to build their own image if they are not satisfied with the image we provide. I recommend that you take a look at imagefactory and consider building your own image which includes LVM. Imagefactory is at the heart of our official image build process inside koji, but it also runs fine as a standalone application, and is part of the standard Fedora distribution.
Note that this breaks, among other things, docker thin provisioning (see #1260189) If you're reluctant to put LVM on the rootfs by default, perhaps an option to do it via cloud-config would be possible?
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.