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

Add overlay2.size daemon storage-opt #32977

Merged
merged 1 commit into from Jun 28, 2017

Conversation

@imkin
Contributor

imkin commented May 2, 2017

This commit adds the overlay2.size option to the daemon daemon storage opts.

The user can override this option by the "docker run --storage-opts" options.

Signed-off-by: Dhawal Yogesh Bhanushali dbhanushali@vmware.com

closes #30491

- What I did

Added the daemon storage opt overlay2.size option

docker daemon --storage-opt overlay2.size=5G

@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin May 3, 2017

Contributor

@GordonTheTurtle @amir73il any comments?

Contributor

imkin commented May 3, 2017

@GordonTheTurtle @amir73il any comments?

@amir73il

LGTM

@rhvgoyal

This comment has been minimized.

Show comment
Hide comment
@rhvgoyal

rhvgoyal May 5, 2017

Contributor

Does this apply to only containers or to image as well?

Contributor

rhvgoyal commented May 5, 2017

Does this apply to only containers or to image as well?

if err != nil {
return nil, err
}
o.quota.Size = uint64(size)

This comment has been minimized.

@rhvgoyal

rhvgoyal May 5, 2017

Contributor

I think we should if we are on xfs and we can enable quota. Otherwise we should fail during Init() time itself if user wants to use a default size but we can't enforce that default size.

@rhvgoyal

rhvgoyal May 5, 2017

Contributor

I think we should if we are on xfs and we can enable quota. Otherwise we should fail during Init() time itself if user wants to use a default size but we can't enforce that default size.

This comment has been minimized.

@rhvgoyal

rhvgoyal May 5, 2017

Contributor

IOW, in Init() this check should be there and driver initialization should fail if quota can't be supported and user asked for it.

@rhvgoyal

rhvgoyal May 5, 2017

Contributor

IOW, in Init() this check should be there and driver initialization should fail if quota can't be supported and user asked for it.

This comment has been minimized.

@amir73il

amir73il May 5, 2017

Contributor

Right. I missed that.

@amir73il

amir73il May 5, 2017

Contributor

Right. I missed that.

This comment has been minimized.

@imkin

imkin May 5, 2017

Contributor

In sync with the other comments have made the change.

@imkin

imkin May 5, 2017

Contributor

In sync with the other comments have made the change.

This comment has been minimized.

@bklau

bklau Jun 21, 2017

@amir73il Q: so the overlay2.size storage opt sets the default for RW layer only or includes the base image(Rootfs)?
Pls clarify.

@bklau

bklau Jun 21, 2017

@amir73il Q: so the overlay2.size storage opt sets the default for RW layer only or includes the base image(Rootfs)?
Pls clarify.

This comment has been minimized.

@amir73il

amir73il Jun 21, 2017

Contributor

Only for RW layer.

@amir73il

amir73il Jun 21, 2017

Contributor

Only for RW layer.

@amir73il

This comment has been minimized.

Show comment
Hide comment
@amir73il

amir73il May 5, 2017

Contributor

The quota is only applied to container root dir, which is where the overlay upper dir is,
so unlike btrfs and devicemapper drivers, 'size' doesn't limit the size of the image at all,
only the size of the changes that container can make to the image.
However that is the 'size' that will be observed by user running 'df /' command inside container.

Contributor

amir73il commented May 5, 2017

The quota is only applied to container root dir, which is where the overlay upper dir is,
so unlike btrfs and devicemapper drivers, 'size' doesn't limit the size of the image at all,
only the size of the changes that container can make to the image.
However that is the 'size' that will be observed by user running 'df /' command inside container.

Show outdated Hide outdated daemon/graphdriver/overlay2/overlay.go Outdated
@rhvgoyal

This comment has been minimized.

Show comment
Hide comment
@rhvgoyal

rhvgoyal May 5, 2017

Contributor

@amir73il We seem to enforce quota restrictions in Create(). And IIUC, that's used both by images as well as container root. So IIUC, this quota will be applied to both images as well as container (after this patch).

Previously, it will not apply to images because option was per container and there was no way to pass this option for images.

Am I missing something?

Contributor

rhvgoyal commented May 5, 2017

@amir73il We seem to enforce quota restrictions in Create(). And IIUC, that's used both by images as well as container root. So IIUC, this quota will be applied to both images as well as container (after this patch).

Previously, it will not apply to images because option was per container and there was no way to pass this option for images.

Am I missing something?

@rhvgoyal

This comment has been minimized.

Show comment
Hide comment
@rhvgoyal

rhvgoyal May 5, 2017

Contributor

I think applying these limits for images is a good idea though. People have raised concerns about pulling images with sparse files in it. And being able to put a limit on the max size of each layer will help prevent somebody trying to explode 1TB sparse file on disk.

Contributor

rhvgoyal commented May 5, 2017

I think applying these limits for images is a good idea though. People have raised concerns about pulling images with sparse files in it. And being able to put a limit on the max size of each layer will help prevent somebody trying to explode 1TB sparse file on disk.

@amir73il

This comment has been minimized.

Show comment
Hide comment
@amir73il

amir73il May 5, 2017

Contributor

I see. confession: I don't know docker that well... I guess applying limits to images make sense. So an image will contain single or multi lower layers, which will all limited cumulatively by the project quota limit?
Specifically, I also don't know what the container '-init' dir is, but it gets assigned a project id as well, so I am guessing it will get a project default quota limit too now.

Contributor

amir73il commented May 5, 2017

I see. confession: I don't know docker that well... I guess applying limits to images make sense. So an image will contain single or multi lower layers, which will all limited cumulatively by the project quota limit?
Specifically, I also don't know what the container '-init' dir is, but it gets assigned a project id as well, so I am guessing it will get a project default quota limit too now.

@rhvgoyal

This comment has been minimized.

Show comment
Hide comment
@rhvgoyal

rhvgoyal May 5, 2017

Contributor

Right. -init is another intermediate layer where docker might want to scribble something and then use it as lower layer for actual container rootfs. So quota will be applied to that too. Though contents written there by docker are very small, so applying quota to -init layer is not a problem.

I think being able to apply it to container rootfs and to image layer are going to be very useful.

Contributor

rhvgoyal commented May 5, 2017

Right. -init is another intermediate layer where docker might want to scribble something and then use it as lower layer for actual container rootfs. So quota will be applied to that too. Though contents written there by docker are very small, so applying quota to -init layer is not a problem.

I think being able to apply it to container rootfs and to image layer are going to be very useful.

@rhvgoyal

This comment has been minimized.

Show comment
Hide comment
@rhvgoyal

rhvgoyal May 5, 2017

Contributor

That's my understanding that every image layer will be limited to project quota specified by overlay2.size. But I also have not spent too much time in looking at overlay2 code. So @imkin might have more definitive answer.

Contributor

rhvgoyal commented May 5, 2017

That's my understanding that every image layer will be limited to project quota specified by overlay2.size. But I also have not spent too much time in looking at overlay2 code. So @imkin might have more definitive answer.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah
Member

thaJeztah commented May 5, 2017

/cc @dmcgowan

@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin May 5, 2017

Contributor

@rhvgoyal I do see that all the layers comply with the "size" parameter.

This, however, is same as what the existing size storage option for the docker run command. So I believe if anything else needs to comply with this "size" param then it should be a holistic issue of the overlayfs2's docker driver here and not in the scope of this PR.

Contributor

imkin commented May 5, 2017

@rhvgoyal I do see that all the layers comply with the "size" parameter.

This, however, is same as what the existing size storage option for the docker run command. So I believe if anything else needs to comply with this "size" param then it should be a holistic issue of the overlayfs2's docker driver here and not in the scope of this PR.

@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin May 5, 2017

Contributor

The powerpc test failure is a flake. #33041

Contributor

imkin commented May 5, 2017

The powerpc test failure is a flake. #33041

@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin May 8, 2017

Contributor

@amir73il Made the suggested changes. Please bless :-)

Contributor

imkin commented May 8, 2017

@amir73il Made the suggested changes. Please bless :-)

@rhvgoyal

This comment has been minimized.

Show comment
Hide comment
@rhvgoyal

rhvgoyal May 8, 2017

Contributor

@imkin, I am just trying to understand the behavior better. Previously though it was in create path, there was no way to pass in this during create for images so it did not impact us.

But with your changes, this being a daemon flag, it will apply to both image layer create and container rootfs. And it will impact image pull.

Given your changes impact that behavior I want to understand the impact on images.

So this will pull size restriction on image layer as well, right? Only thing seems to be that size limit will
be per image layer (and not the whole image if image has multiple layers).

Contributor

rhvgoyal commented May 8, 2017

@imkin, I am just trying to understand the behavior better. Previously though it was in create path, there was no way to pass in this during create for images so it did not impact us.

But with your changes, this being a daemon flag, it will apply to both image layer create and container rootfs. And it will impact image pull.

Given your changes impact that behavior I want to understand the impact on images.

So this will pull size restriction on image layer as well, right? Only thing seems to be that size limit will
be per image layer (and not the whole image if image has multiple layers).

@amir73il

code looks fine to me. still need to understand the implication of image pull. and there is a typo in commit message (daemon daemon)

@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin May 8, 2017

Contributor

@rhvgoyal just now did a docker pull of a image larger than what the overlay2.size parameter allowed.

bash-4.3# docker pull openjdk
Using default tag: latest
latest: Pulling from library/openjdk
cd0a524342ef: Extracting [==================================================>] 52.55 MB/52.55 MB
e39c3ffe4133: Download complete
85334a7c2001: Download complete
b46c5b79125e: Download complete
30d4cb7cc8bc: Download complete
4d273117faaf: Download complete
2b271bed4ca3: Download complete
30e4d8ac7a54: Download complete
45858d68b18d: Download complete
failed to register layer: Error processing tar file(exit status 1): open /usr/share/locale/nb/LC_MESSAGES/tar.mo: disk quota exceeded

So @rhvgoyal @amir73il it docker pull also honors the size parameter. The pull is successful when I increase the value of the "size" param.

Contributor

imkin commented May 8, 2017

@rhvgoyal just now did a docker pull of a image larger than what the overlay2.size parameter allowed.

bash-4.3# docker pull openjdk
Using default tag: latest
latest: Pulling from library/openjdk
cd0a524342ef: Extracting [==================================================>] 52.55 MB/52.55 MB
e39c3ffe4133: Download complete
85334a7c2001: Download complete
b46c5b79125e: Download complete
30d4cb7cc8bc: Download complete
4d273117faaf: Download complete
2b271bed4ca3: Download complete
30e4d8ac7a54: Download complete
45858d68b18d: Download complete
failed to register layer: Error processing tar file(exit status 1): open /usr/share/locale/nb/LC_MESSAGES/tar.mo: disk quota exceeded

So @rhvgoyal @amir73il it docker pull also honors the size parameter. The pull is successful when I increase the value of the "size" param.

@rhvgoyal

This comment has been minimized.

Show comment
Hide comment
@rhvgoyal

rhvgoyal May 8, 2017

Contributor

@imkin, thanks for verifying. I am glad that it works for image layer too.

LGTM

Contributor

rhvgoyal commented May 8, 2017

@imkin, thanks for verifying. I am glad that it works for image layer too.

LGTM

@runcom

This comment has been minimized.

Show comment
Hide comment
@runcom

runcom May 8, 2017

Member

Awesome

Member

runcom commented May 8, 2017

Awesome

@runcom

This comment has been minimized.

Show comment
Hide comment
@runcom

runcom May 8, 2017

Member

I guess design looks to to me as well, @thaJeztah @cpuguy83 can we move this to code review?

Member

runcom commented May 8, 2017

I guess design looks to to me as well, @thaJeztah @cpuguy83 can we move this to code review?

@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin Jun 20, 2017

Contributor

@thaJeztah here is the docs PR docker/cli#215

Contributor

imkin commented Jun 20, 2017

@thaJeztah here is the docs PR docker/cli#215

@thaJeztah

left some questions

Show outdated Hide outdated daemon/graphdriver/overlay2/overlay.go Outdated
}
}
if _, ok := opts.StorageOpt["size"]; !ok {

This comment has been minimized.

@thaJeztah

thaJeztah Jun 21, 2017

Member

Looks like we now always pass opts, even if no option is set on dockerd or is passed with docker run; should the code here check if either opts.StorageOpt is set or d.options.quota.Size is set, and otherwise just keep opts as nil?

@thaJeztah

thaJeztah Jun 21, 2017

Member

Looks like we now always pass opts, even if no option is set on dockerd or is passed with docker run; should the code here check if either opts.StorageOpt is set or d.options.quota.Size is set, and otherwise just keep opts as nil?

This comment has been minimized.

@imkin

imkin Jun 21, 2017

Contributor

When we reach CreateReadWrite we have lost the information whether opts.StorageOpt is defined or not. We only have d.options.quota.Size. Unintialized "d.options.quota.Size" is 0. I am not sure if it is semantically right to assume d.options.quota.Size with "0" as "Not-Initialized". The current "size" option for docker run allows you to define this as "0".

@imkin

imkin Jun 21, 2017

Contributor

When we reach CreateReadWrite we have lost the information whether opts.StorageOpt is defined or not. We only have d.options.quota.Size. Unintialized "d.options.quota.Size" is 0. I am not sure if it is semantically right to assume d.options.quota.Size with "0" as "Not-Initialized". The current "size" option for docker run allows you to define this as "0".

@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin Jun 21, 2017

Contributor

@thaJeztah I could not comment on your second question since it may not be a "git review comment" so paraphrasing you here.

So if we don't want Create to be called with quota; perhaps we should add a non-exported create() that's both called by Create() and CreateReadWrite();

func (d *Driver) Create(id, parent string, opts *graphdriver.CreateOpts) (retErr error) {
	if opts != nil && len(opts.StorageOpt) != 0 && !projectQuotaSupported {
		return fmt.Errorf("--storage-opt is supported only for overlay over xfs with 'pquota' mount option")
	}

	return d.create(id, parent string, opts)
}
The check in Create() could even be;

if opts != nil && len(opts.StorageOpt) != 0 {
    // error...
}
Given that Create() then won't support any options

The check of "projectquotasupport" is not a concern of "Create()" but of CreateReadWrite() since only quota should only be set in the ReadWrite layer. Hence the check is moved to CreateReadWrite.

Contributor

imkin commented Jun 21, 2017

@thaJeztah I could not comment on your second question since it may not be a "git review comment" so paraphrasing you here.

So if we don't want Create to be called with quota; perhaps we should add a non-exported create() that's both called by Create() and CreateReadWrite();

func (d *Driver) Create(id, parent string, opts *graphdriver.CreateOpts) (retErr error) {
	if opts != nil && len(opts.StorageOpt) != 0 && !projectQuotaSupported {
		return fmt.Errorf("--storage-opt is supported only for overlay over xfs with 'pquota' mount option")
	}

	return d.create(id, parent string, opts)
}
The check in Create() could even be;

if opts != nil && len(opts.StorageOpt) != 0 {
    // error...
}
Given that Create() then won't support any options

The check of "projectquotasupport" is not a concern of "Create()" but of CreateReadWrite() since only quota should only be set in the ReadWrite layer. Hence the check is moved to CreateReadWrite.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Jun 21, 2017

Member

The check of "projectquotasupport" is not a concern of "Create()" but of CreateReadWrite() since only quota should only be set in the ReadWrite layer. Hence the check is moved to CreateReadWrite.

The point is that Create() is an exported function, and, while true that it's currently not called with a quota; being an exported function means it can be called in a different code path.

By splitting the Exported Create(), that situation would be covered

Member

thaJeztah commented Jun 21, 2017

The check of "projectquotasupport" is not a concern of "Create()" but of CreateReadWrite() since only quota should only be set in the ReadWrite layer. Hence the check is moved to CreateReadWrite.

The point is that Create() is an exported function, and, while true that it's currently not called with a quota; being an exported function means it can be called in a different code path.

By splitting the Exported Create(), that situation would be covered

@bklau

This comment has been minimized.

Show comment
Hide comment
@bklau

bklau Jun 21, 2017

thaJeztah : Q: How is the default for container storage size set for other drivers like dm , btrfs and zfs? Is this just a one-off for Overlay2 driver only??

bklau commented Jun 21, 2017

thaJeztah : Q: How is the default for container storage size set for other drivers like dm , btrfs and zfs? Is this just a one-off for Overlay2 driver only??

@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin Jun 21, 2017

Contributor

@thaJeztah quota support does not make sense for read layers because they are anyways "readonly". Calling Create directly for setting quota may never be the right way. I could have a private create function that does what Create is doing today. As per your suggestion both Create and CreateReadWrite could call it. However the check in Create could be to completely disallow setting quota directly.

Contributor

imkin commented Jun 21, 2017

@thaJeztah quota support does not make sense for read layers because they are anyways "readonly". Calling Create directly for setting quota may never be the right way. I could have a private create function that does what Create is doing today. As per your suggestion both Create and CreateReadWrite could call it. However the check in Create could be to completely disallow setting quota directly.

@bklau

This comment has been minimized.

Show comment
Hide comment
@bklau

bklau Jun 22, 2017

@imkin @rhvgoyal Earlier goyal did a test that shows that the size parameter also affects the "base image". On the client side, i thought that it just impacted the CoW RW layers.
Isn't this behaviour a discrepancy between what is set on by docker run --storage-opt size=xxx and dockerd --storage-opt overlay2.size=xxx ?? Pls clarify. I refer to below chat:

"@rhvgoyal just now did a docker pull of a image larger than what the overlay2.size parameter allowed.

bash-4.3# docker pull openjdk
Using default tag: latest
latest: Pulling from library/openjdk
cd0a524342ef: Extracting [==================================================>] 52.55 MB/52.55 MB
e39c3ffe4133: Download complete
85334a7c2001: Download complete
b46c5b79125e: Download complete
30d4cb7cc8bc: Download complete
4d273117faaf: Download complete
2b271bed4ca3: Download complete
30e4d8ac7a54: Download complete
45858d68b18d: Download complete
failed to register layer: Error processing tar file(exit status 1): open /usr/share/locale/nb/LC_MESSAGES/tar.mo: disk quota exceeded

So @rhvgoyal @amir73il it docker pull also honors the size parameter. The pull is successful when I increase the value of the "size" param."

bklau commented Jun 22, 2017

@imkin @rhvgoyal Earlier goyal did a test that shows that the size parameter also affects the "base image". On the client side, i thought that it just impacted the CoW RW layers.
Isn't this behaviour a discrepancy between what is set on by docker run --storage-opt size=xxx and dockerd --storage-opt overlay2.size=xxx ?? Pls clarify. I refer to below chat:

"@rhvgoyal just now did a docker pull of a image larger than what the overlay2.size parameter allowed.

bash-4.3# docker pull openjdk
Using default tag: latest
latest: Pulling from library/openjdk
cd0a524342ef: Extracting [==================================================>] 52.55 MB/52.55 MB
e39c3ffe4133: Download complete
85334a7c2001: Download complete
b46c5b79125e: Download complete
30d4cb7cc8bc: Download complete
4d273117faaf: Download complete
2b271bed4ca3: Download complete
30e4d8ac7a54: Download complete
45858d68b18d: Download complete
failed to register layer: Error processing tar file(exit status 1): open /usr/share/locale/nb/LC_MESSAGES/tar.mo: disk quota exceeded

So @rhvgoyal @amir73il it docker pull also honors the size parameter. The pull is successful when I increase the value of the "size" param."

@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin Jun 22, 2017

Contributor

@bklau Initially the idea was to impact all layers. Then based on comments from @dmcgowan and @cpuguy83 we reduced the impact to be on ReadWrite Layer.(rootfs)

Contributor

imkin commented Jun 22, 2017

@bklau Initially the idea was to impact all layers. Then based on comments from @dmcgowan and @cpuguy83 we reduced the impact to be on ReadWrite Layer.(rootfs)

Add overlay2.size daemon storage-opt
This commit adds the overlay2.size option to the daemon daemon
storage opts.

The user can override this option by the "docker run --storage-opt"
options.

Signed-off-by: Dhawal Yogesh Bhanushali <dbhanushali@vmware.com>
@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin Jun 27, 2017

Contributor

@thaJeztah made the changes as per the discussion. Can you check if it satisfies your comments?

Contributor

imkin commented Jun 27, 2017

@thaJeztah made the changes as per the discussion. Can you check if it satisfies your comments?

@thaJeztah

LGTM thanks!

@thaJeztah thaJeztah merged commit acf855b into moby:master Jun 28, 2017

6 checks passed

dco-signed All commits are signed
experimental Jenkins build Docker-PRs-experimental 35307 has succeeded
Details
janky Jenkins build Docker-PRs 43916 has succeeded
Details
powerpc Jenkins build Docker-PRs-powerpc 4280 has succeeded
Details
windowsRS1 Jenkins build Docker-PRs-WoW-RS1 15255 has succeeded
Details
z Jenkins build Docker-PRs-s390x 4004 has succeeded
Details
@stevvooe

This comment has been minimized.

Show comment
Hide comment
@stevvooe

stevvooe Jun 30, 2017

Contributor

@thaJeztah Wish we had taken the feedback in #32977 (comment) before merging this. The parameter overlay2.size is extremely unclear that it is a quota. What if soft and hard quotas are added? What if a different quota system is used to enforce that quota?

Contributor

stevvooe commented Jun 30, 2017

@thaJeztah Wish we had taken the feedback in #32977 (comment) before merging this. The parameter overlay2.size is extremely unclear that it is a quota. What if soft and hard quotas are added? What if a different quota system is used to enforce that quota?

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Jun 30, 2017

Contributor

@stevvooe This is not a new option, only able to specified at the daemon level in addition to per-container.

But sorry, your suggestion definitely got lost in the sea of comments. Review->RequestChanges may help here in the future.
Please open an issue if you think this should still be changed.

Contributor

cpuguy83 commented Jun 30, 2017

@stevvooe This is not a new option, only able to specified at the daemon level in addition to per-container.

But sorry, your suggestion definitely got lost in the sea of comments. Review->RequestChanges may help here in the future.
Please open an issue if you think this should still be changed.

@stevvooe

This comment has been minimized.

Show comment
Hide comment
@stevvooe

stevvooe Jun 30, 2017

Contributor

overlay2.quota.size seems correct.

Contributor

stevvooe commented Jun 30, 2017

overlay2.quota.size seems correct.

@imkin

This comment has been minimized.

Show comment
Hide comment
@imkin

imkin Jun 30, 2017

Contributor

@stevvooe I did respond to you but did not hear back from you.

I am not sure why "quota" should be mentioned. Thats an implementation detail right?

Contributor

imkin commented Jun 30, 2017

@stevvooe I did respond to you but did not hear back from you.

I am not sure why "quota" should be mentioned. Thats an implementation detail right?

@stevvooe

This comment has been minimized.

Show comment
Hide comment
@stevvooe

stevvooe Jun 30, 2017

Contributor

I am not sure why "quota" should be mentioned. Thats an implementation detail right?

"Project Quota" is an implementation detail, yes, but the semantic meaning of size is that this is enforcing a quota. The fact that it is a quota is not an implementation detail.

The conversation is happening in #33903.

Contributor

stevvooe commented Jun 30, 2017

I am not sure why "quota" should be mentioned. Thats an implementation detail right?

"Project Quota" is an implementation detail, yes, but the semantic meaning of size is that this is enforcing a quota. The fact that it is a quota is not an implementation detail.

The conversation is happening in #33903.

albers added a commit to albers/docker-cli that referenced this pull request Jul 3, 2017

Add bash completion for `dockerd --storage-opt overlay2.size`
This adds bash completion for
- docker#215
- moby/moby#32977

Signed-off-by: Harald Albers <github@albersweb.de>

andrewhsu pushed a commit to docker/docker-ce that referenced this pull request Jul 14, 2017

Add bash completion for `dockerd --storage-opt overlay2.size`
This adds bash completion for
- docker/cli#215
- moby/moby#32977

Signed-off-by: Harald Albers <github@albersweb.de>
Upstream-commit: a4b1769bb600edf9c7542247fccc3e7dae074da0
Component: cli

@amir73il amir73il referenced this pull request Jul 21, 2017

Closed

Xfs quota for overlay #24807

alshabib added a commit to alshabib/cli that referenced this pull request Aug 1, 2017

Add bash completion for `dockerd --storage-opt overlay2.size`
This adds bash completion for
- docker#215
- moby/moby#32977

Signed-off-by: Harald Albers <github@albersweb.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment