Re: [atomic-devel] Help with testing AMI's

[Dusty Mabe <dustymabe gmail com>]

On Mon, Sep 08, 2014 at 02:58:58PM -0400, Colin Walters wrote:
> On Sat, Sep 6, 2014, at 10:21 PM, Dusty Mabe wrote:
> > 
> > Are you aware of the issue I referred to earlier? Basically this means
> > that 
> > if there is more than one partition on the disk image (as is the case for
> > these 
> > atomic images) then it won't get resized appropriately. As a result I end
> > up only
> > using ~8G of disk space when I really allocated 20G, 30G, etc.. for the
> > primary disk. 
> 
> Right.  This is a complex issue and gets to the fact that our Docker
> storage setup is still suboptimal.
> 
> Ultimately what we want is to have a dedicated DM pool for the Docker
> storage, distinct from the OS.

I agree that we want a dedicated storage pool separate from the
OS but it is not our responsibility to do this within the "cloud
image". We just need to ship sane defaults (i.e something that works)
but then allow for the user to make docker storage out of ehemeral
disks, volumes, etc.. I think this can already be done by the user by 
leveraging cloud-init. 

I think the problem I raised is somewhat unrelated, however. This
simply has to do with the fact that growpart within RHEL/CentOS 7
isn't capable of expanding the last partition on the disk if the disk
has more than 1 partition. If I wasn't diligent and didn't check the
cloud-init logs or the space then I wouldn't have known that my
partition didn't get resized appropriately.

This doesn't affect Fedora 21 as the bug[1] has been fixed [2]. 

> 
> If we were going to be a bit more adventurous with LVM, we'd use thin
> provisioning.
> 
> Regardless, we have a distinction between Docker storage and host
> storage.  In that scenario, when the cloud provider allocates us say
> 30G, how do we proportion?  My initial take is we'd grow the Docker
> storage pool, but I think ultimately this will need to be configurable
> (via e.g. cloud-init?).  In the case where I'm keeping a lot of data on
> the host system and using bind mounts to expose it to containers, for
> example.  
> 
> A short term fix would be LVM-based default.  Hmm...wasn't there a
> variant of growpart around that worked on LVM?

I don't know if LVM will solve the problem I raise. Can you elaborate?

Thanks,
Dusty

[1] - https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1244662
[2] - https://github.com/karelzak/util-linux/commit/84ac311212c06963d616b1b9a40644842f9adabd