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