[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] docker storage setup

I tested it with this Anaconda partitioning:

/boot 300M ext4
/ on 3G LV xfs (VG taking up all the space on disks selected for installation)
swap on the root's VG calculated automatically

and it seems to work.

This is what we probably can set as autopart default for Atomic installclass
(as opposed to current autopart wher root's LV takes up all free space on VG).

On 10/16/2014 10:57 PM, Andy Grimm wrote:
FWIW, I now have something somewhat package-able here:

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
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,
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

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

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.  :)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]