openstack
/
kuryr-kubernetes
Code Issues Proposed changes

Replace Chinese punctuation with English punctuation 

Change-Id: I2a1f0dbd22ee58e056fcdcc65ae98c11a4409c69
This commit is contained in:
chengebj5238 2018-02-05 16:48:17 +08:00
parent a6f0562564
commit b8a56ad94d
3 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
doc/source/devref/kuryr_kubernetes_design.rst
View File

@ -68,7 +68,7 @@ Kuryr Controller Design
-----------------------
Controller is responsible for watching Kubernetess API endpoints to make sure
that the corresponding model is maintained in Neutron. Controller updates K8s
resources endpoints’ annotations to keep neutron details required by the CNI
resources endpoints' annotations to keep neutron details required by the CNI
driver as well as for the model mapping persistency.
Controller is composed from the following components:
@ -76,7 +76,7 @@ Controller is composed from the following components:
Watcher
~~~~~~~
Watcher is a common software component used by both the Controller and the CNI
driver. Watcher connects to Kubernetes API. Watcher’s responsibility is to observe the
driver. Watcher connects to Kubernetes API. Watcher's responsibility is to observe the
registered (either on startup or dynamically during its runtime) endpoints and
invoke registered callback handler (pipeline) to pass all events from
registered endpoints.
@ -88,15 +88,15 @@ several 'wrapper' event handlers that can be composed to implement Controller
handling pipeline.
**Retry** Event Handler is used for handling specified failures during event
processing. It can be used to ‘wrap’ another EventHandler and in case of
processing. It can be used to 'wrap' another EventHandler and in case of
specified error will retry the wrapped event handler invocation within
specified timeout. In case of persistent failure, Retry will raise the wrapped
EventHandler exception.
**Async** Event Handler is used to execute event handling asynchronously.
Events are grouped based on the specified ‘thread_groups’. Events of the same
Events are grouped based on the specified 'thread_groups'. Events of the same
group are processed in order of arrival. Thread group maps to an unique K8s
resource (each Pod, Service, etc.). Async can be used to ‘wrap’ another
resource (each Pod, Service, etc.). Async can be used to 'wrap' another
EventHandler. Queues per thread group are added dynamically once relevant
events arrive and removed once queue is empty.
@ -135,7 +135,7 @@ setting OBJECT_KIND) and is expected to implement at least one of the methods
of the base class to handle at least one of the ADDED/MODIFIED/DELETED events
of the Kubernetes object. For details, see `k8s-api <https://github.com/kubernetes/kubernetes/blob/release-1.4/docs/devel/api-conventions.md#types-kinds>`_.
Since both ADDED and MODIFIED event types trigger very similar sequence of
actions, Handler has ‘on_present’ method that is invoked for both event types.
actions, Handler has 'on_present' method that is invoked for both event types.
The specific Handler implementation should strive to put all the common ADDED
and MODIFIED event handling logic in this method to avoid code duplication.
@ -160,7 +160,7 @@ NeutronPodVifDriver
~~~~~~~~~~~~~~~~~~~
PodVifDriver subclass should implement request_vif, release_vif and
activate_vif methods. In case request_vif returns Vif object in down state,
Controller will invoke activate_vif. Vif ‘active’ state is required by the
Controller will invoke activate_vif. Vif 'active' state is required by the
CNI driver to complete pod handling.
The NeutronPodVifDriver is the default driver that creates neutron port upon
Pod addition and deletes port upon Pod removal.
@ -183,9 +183,9 @@ With VIF object loaded from the Pod object annotation, the CNI driver performs
Pod plugging. Kuryr-K8s CNI driver uses ov_vif library to perform Pod plug and
unplug operations. The CNI driver should complete its job and return control to
Kubelet when all the network plugging is completed.
In the cases when Neutron initially creates port in ‘Down’ state, CNI driver
In the cases when Neutron initially creates port in 'Down' state, CNI driver
will plug the Pod, but will have to watch the Pod annotations for vif state
change to ‘Active’ before returning the control to the caller.
change to 'Active' before returning the control to the caller.
.. image:: ../../images/pod_creation_flow.png
:alt: Controller-CNI interaction

2
doc/source/devref/kuryr_kubernetes_ocp_route_design.rst
View File

@ -102,7 +102,7 @@ This section describes in details the following scenarios:
'mynamespace_s1'.
* The OCP-Route handler will create L7 rule and L7 policy, the L7
policy direct it's filtered traffic towards ‘mynamespace_s1’ pool.
policy direct it's filtered traffic towards 'mynamespace_s1' pool.
* Service/Endpoints is created under namespace 'mynamespace'

14
doc/source/specs/queens/network_policy.rst
View File

@ -46,7 +46,7 @@ Each network policy has 3 main parts [2]_:
In order to support network-policy, kuryr-kubernetes should handle all the
events that are related to the network-policies and translate them into
Neutron objects for apply an equivalent network-topology to the one defined by
the Kubernetes policies. Neutron doesn’t have a security API that is equivalent
the Kubernetes policies. Neutron doesn't have a security API that is equivalent
to the the kubernetes-network-policy. The translation should be done carefully
in order to achieve eventually consistent required topology, and avoid
corner-cases and race conditions.
@ -82,7 +82,7 @@ the Kuryr controller.
Translate Kubernetes policy to Neutron security-group
-----------------------------------------------------
‘Allow all’ policy [3]_
'Allow all' policy [3]_
#######################
Network policy that allows all traffic, should be translated to
Security group with one rule that allows all traffic.
@ -99,7 +99,7 @@ Example for allow all egress traffic:
}
}
‘Deny all’ policy [6]_
'Deny all' policy [6]_
######################
Translate to an empty-security-group.
@ -112,11 +112,11 @@ Can be translated to security-group-rules ingress/egress traits.
IpBlock:
########
Can be done by “remote ip prefix” trait in security-group-rule as both
Can be done by "remote ip prefix" trait in security-group-rule as both
use CIDRs. In case of Exceptions (It's an inner CIDR's of the ipBlock, that
should be excluded from the rule), the ip-range should be broken into pieces
that cover the all ip-block without the exception.
For example, if there is Ip-block :”1.1.1.0/24 except 1.1.1.0/26”, Kuryr should
For example, if there is Ip-block :"1.1.1.0/24 except 1.1.1.0/26", Kuryr should
create security-groups-rules with 1.1.1.128/25 an 1.1.1.64/26).
podSelectors
@ -422,13 +422,13 @@ Let's assume that following policy is created (taken from k8s tutorial [8]_):
* Attach the annotation with security-policy-id to p1.
* Set a watch on the query - “Match-label : {role:db}” , the watch
* Set a watch on the query - "Match-label : {role:db}" , the watch
callback of this watch will update the security-group annotation on
the updated/new pods that are selected by this query.
* Create a match for the ingress/egress group:
* Set watch on the query : “match-labels {role:frontend}” , watch
* Set watch on the query : "match-labels {role:frontend}" , watch
callback will add all pods that are selected by this query to the
security-group [test-network-policy-uid]_in.