As suggested in https://github.com/docker/docker/pull/14004/files#r34022527
The concern there is we can't differentiate whether user explicitly
asked for an invalid value of -1 or he did not specify anything.
I don't think this would be a problem, because:
- like all other default values like zero, we can't differentiate
user specify it or not, most of which, zeros are also invalid, so
default is default, we show these default values in help info,
so users would know if they set value as default, it'll be like
they set nothing.
- we can't do this kind of string check in REST api request, so
it'll make the behave different from docker command and RESTapi.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Closes#14621
This one grew to be much more than I expected so here's the story... :-)
- when a bad port string (e.g. xxx80) is passed into container.create()
via the API it wasn't being checked until we tried to start the container.
- While starting the container we trid to parse 'xxx80' in nat.Int()
and would panic on the strconv.ParseUint(). We should (almost) never panic.
- In trying to remove the panic I decided to make it so that we, instead,
checked the string during the NewPort() constructor. This means that
I had to change all casts from 'string' to 'Port' to use NewPort() instead.
Which is a good thing anyway, people shouldn't assume they know the
internal format of types like that, in general.
- This meant I had to go and add error checks on all calls to NewPort().
To avoid changing the testcases too much I create newPortNoError() **JUST**
for the testcase uses where we know the port string is ok.
- After all of that I then went back and added a check during container.create()
to check the port string so we'll report the error as soon as we get the
data.
- If, somehow, the bad string does get into the metadata we will generate
an error during container.start() but I can't test for that because
the container.create() catches it now. But I did add a testcase for that.
Signed-off-by: Doug Davis <dug@us.ibm.com>
- Refactor opts.ValidatePath and add an opts.ValidateDevice
ValidePath will now accept : containerPath:mode, hostPath:containerPath:mode
and hostPath:containerPath.
ValidateDevice will have the same behavior as current.
- Refactor opts.ValidateEnv, opts.ParseEnvFile
Environment variables will now be validated with the following
definition :
> Environment variables set by the user must have a name consisting
> solely of alphabetics, numerics, and underscores - the first of
> which must not be numeric.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Memory swappiness option takes 0-100, and helps to tune swappiness
behavior per container.
For example, When a lower value of swappiness is chosen
the container will see minimum major faults. When no value is
specified for memory-swappiness in docker UI, it is inherited from
parent cgroup. (generally 60 unless it is changed).
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
There is no reason to error out or not do what the user expects when -i
is specified on the cli. We should always attach to the stdin of the
container in this situation.
Closes#14390
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
By convention /pkg is safe to use from outside the docker tree, for example
if you're building a docker orchestrator.
/nat currently doesn't have any dependencies outside of /pkg, so it seems
reasonable to move it there.
This rename was performed with:
```
gomvpkg -vcs_mv_cmd="git mv {{.Src}} {{.Dst}}" \
-from github.com/docker/docker/nat \
-to github.com/docker/docker/pkg/nat
```
Signed-off-by: Peter Waller <p@pwaller.net>
This commit also brings in the ability to specify a default network and its
corresponding driver as daemon flags. This helps in existing clients to
make use of newer networking features provided by libnetwork.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Signed by all authors:
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Signed-off-by: David Calavera <david.calavera@gmail.com>
Signed-off-by: Jeff Lindsay <progrium@gmail.com>
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Signed-off-by: Luke Marsden <luke@clusterhq.com>
Signed-off-by: David Calavera <david.calavera@gmail.com>
ParseRestartPolicy is useful function for third party go programs to use
so that they can parse the restart policy in the same way that Docker
does
Signed-off-by: Darren Shepherd <darren@rancher.com>
Adds more documentation for labels and adds the label instruction to the
man-pages.
Also included is a document called "Labels - custom meta-data in Docker"
in the user-guide, this is still a work-in-progress I started to describe
the "namespaces" conventions, an example on storing structured data.
I ran a bit "out of steam" (writers block?) on that document, but kept
it in (for now), in case it still ends up useful.
The Remote API documentation changes will need to be moved to the
docker_remote_api_v1.18.md document when rebasing the whole PR.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Darren Shepherd <darren@rancher.com>
David Calavera
Qiang Huang
Sebastiaan van Stijn
Doug Davis
Mrunal Patel
Vincent Demeester
Raghavendra K T
Michael Crosby
Lei Jitang
wlan0
Antonio Murdaca
Peter Waller
John Howard
Madhu Venugopal
Antonio Murdaca
Arnaud Porterie
Darren Shepherd
Ma Shimiao
Jessie Frazelle
HuKeping
Brian Goff
willhf
Vishnu Kannan
Alexander Morozov
Sebastiaan van Stijn