Here is a first step to implement a new API. Currently the init
processes is executed without namespaces and cgroups.
Signed-off-by: Andrew Vagin <avagin@openvz.org>
This modifies Load in the factory to return a ContainerInfo interface
that is the read only view of the container when it is loaded.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Add a rich Error type to the libcontainer package and use it in the API so
that callers can:
* Check for a specific error without depending on an error string,
* Obtain the stack trace of the function or method which detected the error.
The Error type provides a typed error code and a stack trace. The error code
identifies the error and enables the caller to test for it without being
sensitive to changes in the error text. The stack trace identifies the point
at which the error was detected. The combination of error code and stack trace
will enable errors to be diagnosed much more easily and with less guesswork
than when raw string-based errors are used.
The Error type conforms to the error interface and its Error method prints a
short error message. The Detail method provides a verbose error message
including the stack trace.
Notes:
1. There is an unfortunate precedent in the Go standard library which uses
variables to define errors. Checking for a specific error involves a string
comparison and assumes the corresponding variable has not been updated. It is
more robust and efficient to identify errors with integer-based types and
associated constants, although errors should still include a string
description for ease of use by humans.
2. It is not feasible to assign distinct types to Factory and Container
error codes because common errors such as SystemError cannot be declared in
two places and the names of the error codes then need to be decorated. This is
less readable.
Signed-off-by: Steve Powell <spowell@pivotal.io>
add format description for `id` string;
add "invalid format" error for `id` string;
remove initial capitals on references to parameter names;
remove reference to `initialConfig`;
add description of id checking.
Signed-off-by: Steve Powell <spowell@pivotal.io>
The Initialize method is responsible for creating a new Container instance
and calling it Create makes the factory pattern more obvious. Clearly
creating a Container instance involves initialising the instance.
Docker-DCO-1.1-Signed-off-by: Glyn Normington <gnormington@gopivotal.com> (github: glyn)