openstack/magnum
Code Issues Proposed changes

Fix D001 Line too long error

Browse Source 
Reformated documents to fix D001 Line too long error, during
tox -edocs

Change-Id: I5a2cb63ce6ac4db172b7b9be0254bd2110fc2285
Closes-Bug: #1502757
This commit is contained in:
Egor Guz 2015-10-04 22:28:57 -07:00
parent 6e5256b809
commit f2354c3a42
2 changed files with 29 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
doc/source/dev/dev-kubernetes-load-balancer.rst
View File

@ -38,10 +38,11 @@ Kubernetes to use.
In the current implementation, the cluster administrator needs to manually In the current implementation, the cluster administrator needs to manually
perform this step. We are looking into several ways to let Magnum automate perform this step. We are looking into several ways to let Magnum automate
this step in a secure manner. This means that after the Kubernetes cluster is this step in a secure manner. This means that after the Kubernetes cluster is
initially deployed, the load balancer support is disabled. If the administrator initially deployed, the load balancer support is disabled. If the
does not want to enable this feature, no further action is required. All the administrator does not want to enable this feature, no further action is
services will be created normally; services that specify the load balancer required. All the services will be created normally; services that specify the
will also be created successfully, but a load balancer will not be created. load balancer will also be created successfully, but a load balancer will not
be created.
To enable the load balancer, log into each master node of your bay and To enable the load balancer, log into each master node of your bay and
perform the following steps: perform the following steps:
@ -85,11 +86,11 @@ perform the following steps:
This only needs to be done once. The steps can be reversed to disable the This only needs to be done once. The steps can be reversed to disable the
load balancer feature. Before deleting the Kubernetes cluster, make sure to load balancer feature. Before deleting the Kubernetes cluster, make sure to
delete all the services that created load balancers. Because the Neutron objects delete all the services that created load balancers. Because the Neutron
created by Kubernetes are not managed by Heat, they will not be deleted by Heat objects created by Kubernetes are not managed by Heat, they will not be
and this will cause the bay-delete operation to fail. If this occurs, delete deleted by Heat and this will cause the bay-delete operation to fail. If this
the neutron objects manually (lb-pool, lb-vip, lb-member, lb-healthmonitor) and occurs, delete the neutron objects manually (lb-pool, lb-vip, lb-member,
then run bay-delete again. lb-healthmonitor) and then run bay-delete again.
Steps for the users Steps for the users
=================== ===================
@ -198,8 +199,8 @@ The endpoint for nginx can now be accessed at this floating IP::
http://172.24.4.78:80 http://172.24.4.78:80
NOTE: it is not necessary to indicate port :80 here but it is shown to correlate with NOTE: it is not necessary to indicate port :80 here but it is shown to
the port that was specified in the service manifest. correlate with the port that was specified in the service manifest.
How it works How it works
============ ============
@ -235,9 +236,9 @@ These Neutron objects can be verified as follows. For the load balancer pool::
| e59ea983-c6e8-4cec-975d-89ade6b59e50 | k8sbayv1-iypacicrskib-etcd_pool-qbpo43ew2m3x | haproxy | ROUND_ROBIN | HTTP | True | ACTIVE | | e59ea983-c6e8-4cec-975d-89ade6b59e50 | k8sbayv1-iypacicrskib-etcd_pool-qbpo43ew2m3x | haproxy | ROUND_ROBIN | HTTP | True | ACTIVE |
+--------------------------------------+----------------------------------------------+----------+-------------+----------+----------------+--------+ +--------------------------------------+----------------------------------------------+----------+-------------+----------+----------------+--------+
Note that 2 load balancers already exist to implement high availability for the cluster (api and ectd). Note that 2 load balancers already exist to implement high availability for the
The new load balancer for the Kubernetes service uses the TCP protocol and has a name assigned by cluster (api and ectd). The new load balancer for the Kubernetes service uses
Kubernetes. the TCP protocol and has a name assigned by Kubernetes.
For the members of the pool:: For the members of the pool::
@ -250,8 +251,9 @@ For the members of the pool::
| f222b60e-e4a9-4767-bc44-ffa66ec22afe | 10.0.0.6 | 31157 | 1 | True | ACTIVE | | f222b60e-e4a9-4767-bc44-ffa66ec22afe | 10.0.0.6 | 31157 | 1 | True | ACTIVE |
+--------------------------------------+----------+---------------+--------+----------------+--------+ +--------------------------------------+----------+---------------+--------+----------------+--------+
Again, 2 members already exist for high availability and they serve the master node at 10.0.0.5. Again, 2 members already exist for high availability and they serve the master
The new member serves the minion at 10.0.0.6, which hosts the Kubernetes service. node at 10.0.0.5. The new member serves the minion at 10.0.0.6, which hosts the
Kubernetes service.
For the monitor of the pool:: For the monitor of the pool::
@ -275,9 +277,10 @@ For the VIP of the pool::
| fc62cf40-46ad-47bd-aa1e-48339b95b011 | etcd_pool.vip | 10.0.0.4 | HTTP | True | ACTIVE | | fc62cf40-46ad-47bd-aa1e-48339b95b011 | etcd_pool.vip | 10.0.0.4 | HTTP | True | ACTIVE |
+--------------------------------------+----------------------------------+----------+----------+----------------+--------+ +--------------------------------------+----------------------------------+----------+----------+----------------+--------+
Note that the VIP is created on the private network of the cluster; therefore it has an internal Note that the VIP is created on the private network of the cluster; therefore
IP address of 10.0.0.7. This address is also associated as the "external address" of the Kubernetes it has an internal IP address of 10.0.0.7. This address is also associated as
service. You can verify in Kubernetes by running the kubectl command:: the "external address" of the Kubernetes service. You can verify in Kubernetes
by running the kubectl command::
kubectl get services kubectl get services
NAME LABELS SELECTOR IP(S) PORT(S) NAME LABELS SELECTOR IP(S) PORT(S)
@ -285,6 +288,7 @@ service. You can verify in Kubernetes by running the kubectl command::
nginxservice app=nginx app=nginx 10.254.122.191 80/TCP nginxservice app=nginx app=nginx 10.254.122.191 80/TCP
10.0.0.7 10.0.0.7
On GCE, the networking implementation gives the load balancer an external address automatically. On GCE, the networking implementation gives the load balancer an external
On OpenStack, we need to take the additional step of associating a floating IP to the load balancer. address automatically. On OpenStack, we need to take the additional step of
associating a floating IP to the load balancer.

7
specs/tls-support-magnum.rst
View File

@ -101,9 +101,10 @@ with each case.
3.1.2.1. Using Magnum script 3.1.2.1. Using Magnum script
---------------------------- ----------------------------
This script will generate both server and client certificates on Kubernetes master This script will generate both server and client certificates on Kubernetes
node. Hence only client certificates needs to be copied to magnum host node. master node. Hence only client certificates needs to be copied to magnum host
To copy these files, the script will make a call to magnum-api to store files. node. To copy these files, the script will make a call to magnum-api to store
files.
3.1.2.2. Using Barbican 3.1.2.2. Using Barbican
----------------------- -----------------------