Re: [atomic-devel] docker storage setup

[Andy Grimm <agrimm gmail com>]

FWIW, I now have something somewhat package-able here:
https://github.com/a13m/docker-storage-setup

I have tested several cases with this code, and it seems to be working
(as long as you use partx from
https://bugzilla.redhat.com/show_bug.cgi?id=1149278 ... I dropped a
patched version in /usr/local/sbin on my system for testing).

I still don't have an example of using cloud-init to populate
/etc/sysconfig/docker-storage-setup ; I'll work on that.


On Wed, Oct 15, 2014 at 9:25 AM, Andy Grimm <agrimm gmail com> wrote:
> On Tue, Oct 14, 2014 at 10:39 PM, Colin Walters <walters verbum org> wrote:
>> I can definitely see this evolving into some other language (if it was
>> Python, it could use python-blivet, if it was C, it's a lot easier to
>> talk to LVM directly).  Python would probably be OK given that it's a
>> one-shot service and not resident in memory.
>
> I avoided python because every few months somebody talks about kicking
> it out of the base image.  :) And I avoided C because that just takes
> longer for me to write a proof-of-concept.  I am definitely in favor
> of evolution in either direction.
>
>> One major thing; to put this together, we also need to edit
>> /etc/sysconfig/docker-storage.
>
> Yep.  Since I was still just toying with getting it to create the
> right VGs and LVs, I had left out the bit about updating that config.
> Should be straightforward to add.
>
>> In the cloud case, the device name that an EBS volume will use is not
>> necessarily going to be predictable, and that seems like it'd make it
>> harder to use this.
>
> My assumption was that, for initial setup in the cloud case, a user
> will be doing something in cloud-init to generate the sysconfig file
> with devices after inspecting metadata, /proc/partitions, whatever.
> But I'm interested in other ideas here.  I always forget about drive
> mappings being unpredictable (or that least uncustomizable) in the KVM
> world... is that still the case?  I spend most of my time in the AWS
> world, and take predictable drive mapping for granted.
>
>> Say an admin starts out with a micro instance to
>> toy with, but stores data persistently in an EBS volume they've run
>> "pvcreate" on.  Then they want to upgrade to m1.large, and attach the
>> existing volume to the new instance.
>> In this case, the unique predictable identifier would be the PV UUID,
>> right?
>
> The VG, LV, and PV all have UUIDs, which you can use to differentiate
> when necessary.  In the case you described, though, wouldn't the admin
> just want to specify the VG name that they had used?  VG name
> collisions are possible, but in the case you described, it would have
> to be intentional.  Anyway, this made me realize that the code I
> posted does not properly handle the situation where the docker-data
> and docker-meta LVs already exist in the specified VG, and it should.
> I think that's all that's necessary here at the moment.
>
>> There are a lot of scenarios here, and we're not going to be able to
>> capture them all of course.  I think this will work well for "boot OS
>> and have storage expand on default disk" case which is definitely the
>> most important for initial experience.  Admins doing serious Docker in
>> production will need to be able to dive into the storage guide and LVM
>> directly.
>
> Agreed.
>
>> BTW, I tested your script by stopping docker.service and deleting the
>> docker-data/docker-meta from an existing instance, and I had to change
>> this:
>>
>> diff --git a/docker-storage-setup.sh b/docker-storage-setup.sh
>> index 64af49a..13d5a0b 100644
>> --- a/docker-storage-setup.sh
>> +++ b/docker-storage-setup.sh
>> @@ -139,7 +139,7 @@ fi
>>  # more difficult do to the range of possible inputs.
>>  VG_FREE_EXTS=$( vgs --noheadings --nosuffix --units s -o vg_free $VG )
>>  META_SIZE=$(( $VG_FREE_EXTS / 1000 + 1 ))
>> -lvcreate -l ${META_SIZE}S -n docker-meta $VG
>> +lvcreate -L ${META_SIZE}S -n docker-meta $VG
>>  if [ -n "$DATA_SIZE" ]; then
>>    # TODO: Error handling when DATA_SIZE > available space.
>>    lvcreate -L $DATA_SIZE -n docker-data $VG
>
> Oh, thanks.  I had not tested this exact version of the script yet, so
> I'm glad it almost worked.  :)
>
> --Andy