From 6583f58ad06554d3f8b936e1f193e581ed157321 Mon Sep 17 00:00:00 2001 From: Pradeep Kumar Singh Date: Thu, 15 Dec 2016 07:54:26 +0000 Subject: [PATCH] Add 'specs' directory in tox.ini This patch adds 'specs' directory in tox.ini, so that 'tox -e docs' can validate the .rst files under specs directory. Change-Id: I899cc24eb7ef4df3afaa47bc34827037fcc0cd36 --- specs/container-interactive-mode.rst | 47 +++++++++++++++------------- tox.ini | 2 +- 2 files changed, 26 insertions(+), 23 deletions(-) diff --git a/specs/container-interactive-mode.rst b/specs/container-interactive-mode.rst index 498296ca5..325a8ecb5 100644 --- a/specs/container-interactive-mode.rst +++ b/specs/container-interactive-mode.rst @@ -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 --------------- diff --git a/tox.ini b/tox.ini index dcffa02b3..2b960937a 100644 --- a/tox.ini +++ b/tox.ini @@ -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]