Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Consistent device usage in devicemapper examples #3032

Closed
wants to merge 3 commits into from

Conversation

LongLiveCHIEF
Copy link

Proposed changes

The existing docs use inconsistent names for the docker volume, and the thinpool logical volume names. I've updated the docs to use docker consistently as the volume group name, and docker/thinpool as the logical volume in all examples.

this makes the docs easier to comprehend, since users don't have to go through multiple times to realize the names of volumes keep switching halfway through the example.

The existing docs use inconsistent names for the docker volume, and the thinpool logical volume names.  I've updated the docs to use `docker` consistently as the volume group name, and `docker/thinpool` as the logical volume in all examples.

this makes the docs easier to comprehend, since users don't have to go through multiple times to realize the names of volumes keep switching halfway through the example.
It seems latest versions of docker don't want the fully qualified device path in the `dm.thinpooldev` setting.  Systemd fails to start docker daemon if I use `/dev/vgname/lvname` _or_ `/dev/mapper/vgname-lvname`.  When using devicemapper, all it wants is the name of the thinpool.
With no containers running, the output of `lsblk` will only show the thin lvm devices, and not the dm thin volumes.
@LongLiveCHIEF LongLiveCHIEF changed the title Consistent device usage in devicemapper examples WIP: Consistent device usage in devicemapper examples Apr 26, 2017
@mdlinville
Copy link

How is this coming along?

@mdlinville
Copy link

This is still listed as WIP and has a merge conflict. Any update?

@LongLiveCHIEF
Copy link
Author

There was a recent update to projectatomic/container-storage-setup, and I've been working through issues in consistency between manual setup using the current docs, running the latest css, and some issues with selinux enabled hosts.

It's already been a long week with this one, but I hope to be able to take definitive action on this PR by the end of the week.

@LongLiveCHIEF
Copy link
Author

The issue mentioned in css: passing -n ftype=1 hits the nail on the head with the selinux issues.

Especially running dind scenarios, volume creation fails within an outer contain because the given root path for docker on most CentOS/RHEL distro's isn't formatted correctly when left to docker to create the directory.

@LongLiveCHIEF
Copy link
Author

After reviewing the changes, I don't think there's any point in rebasing. I think the upstream changes covered everything I was going to do with this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants