openstack/zun
Code Issues Proposed changes

Add 'specs' directory in tox.ini

Browse Source 
This patch adds 'specs' directory in tox.ini, so that
'tox -e docs' can validate the .rst files under specs
directory.

Change-Id: I899cc24eb7ef4df3afaa47bc34827037fcc0cd36
This commit is contained in:
Pradeep Kumar Singh 2016-12-15 07:54:26 +00:00
parent 27229f5b50
commit 6583f58ad0
2 changed files with 26 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
specs/container-interactive-mode.rst
View File

@ -23,15 +23,16 @@ interactive interface. Take docker driver as the first container driver.
Problem description
===================
Zun containers now take Docker as the first container driver. Docker can use
"docker run -it" to enter into the interactive mode, where user can do operations
looks like chroot. Zun use docker-py as the interface to get access the docker
deamon.
"docker run -it" to enter into the interactive mode, where user can do
operations looks like chroot. Zun use docker-py as the interface to get access
the docker deamon.
To reach the goal of realizing the container interactive, zun needs to pass the
correct parameters when create container and start container at the time
it has been created, so that a tty will be created inside the container. User
can connect the stdin, stdout, stderr to get a pseudo tty in local client. Since
Kubernetes realize this function, refer to Kubernetes realization is a feasible way.
can connect the stdin, stdout, stderr to get a pseudo tty in local client.
Since Kubernetes realize this function, refer to Kubernetes realization is a
feasible way.
https://github.com/kubernetes/kubernetes/pull/3763
@ -40,17 +41,18 @@ http://kubernetes.io/docs/user-guide/kubectl/kubectl_run/
Proposed change
===============
1. Let each Docker daemon listens to 0.0.0.0:port, so that zun-api will easily talk
with Docker deamon. This might reduce the load on zun-compute a bit and let
zun-compute have more rooms to serve other workload.
1. Let each Docker daemon listens to 0.0.0.0:port, so that zun-api will easily
talk with Docker deamon. This might reduce the load on zun-compute a bit
and let zun-compute have more rooms to serve other workload.
2. For docker daemon, the new two paramaters about tty and stdin_open should
be added to the container field and corresponding database.
3. Zun api will wait for the container start and get the websocket link to zun CLIs.
3. Zun api will wait for the container start and get the websocket link to zun
CLIs.
4. For python-zunclient, it will filter the parameters and pick up the correct
for interactive mode. Then will open the connection to container at local
terminal after the "zun run" command return. Zun CLIs will directly connect the
websocket link from Docker daemon (for authorization problem, will fix it in the
follow bp/bug).
terminal after the "zun run" command return. Zun CLIs will directly connect
the websocket link from Docker daemon (for authorization problem, will fix
it in the follow bp/bug).
The diagram below offers an overview of the interactive mode architecture.
E.g : zun run -it --name test --image cirros --command "/bin/sh"
@ -60,8 +62,8 @@ https://github.com/kevin-zhaoshuai/workflow
Design Principles
-----------------
1. Keep commonality for Docker and other container driver. Easy for other driver
integration.
1. Keep commonality for Docker and other container driver. Easy for other
driver integration.
2. Take into account all the interactive conditions.
3. Pty connection functions need to be independent and extensible
@ -71,18 +73,19 @@ Alternatives
Data model impact
-----------------
Add some fields to container object, including "tty" "stdin_open" and a flag to show whether the
container has been attached, maybe "attached" = "true"/"false".
Add some fields to container object, including "tty" "stdin_open" and a flag
to show whether the container has been attached,
maybe "attached" = "true"/"false".
REST API impact
---------------
Add an new API for "zun attach"
Zun CLIs will first send the message to zun-api, zun-api will directly talk with Docker
daemon. Then after the container is successfully started, zun-api notify
zun CLIs with the attach url. Zun CLIs will attach its stdin ,stdout and stderr to
the container.
Since zun CLIs connect with the websocket in Docker daemon, so that will not hijack HTTP
request (from zun CLIs to zun api), user can do another zun api command in another terminal.
Zun CLIs will first send the message to zun-api, zun-api will directly talk
with Docker daemon. Then after the container is successfully started, zun-api
notify zun CLIs with the attach url. Zun CLIs will attach its stdin ,stdout
and stderr to the container. Since zun CLIs connect with the websocket in
Docker daemon, so that will not hijack HTTP request (from zun CLIs to zun api),
user can do another zun api command in another terminal.
Security impact
---------------

2
tox.ini
View File

@ -36,7 +36,7 @@ commands = python setup.py test --coverage --testr-args='{posargs}'
[testenv:docs]
commands =
doc8 -e .rst doc/source/ CONTRIBUTING.rst HACKING.rst README.rst
doc8 -e .rst specs/ doc/source/ CONTRIBUTING.rst HACKING.rst README.rst
python setup.py build_sphinx
[testenv:debug]