[Trivial fix] Correct spelling error
Small modification to correct spelling mistake. Change-Id: Ia77a27583199c3f54a4316dc52a416cb9a1ff95f
This commit is contained in:
parent
5ca2fbf802
commit
f0a2ed32b1
|
@ -57,7 +57,7 @@ The ideal long-term solution (which is one that this proposal drives towards)
|
|||
is to consume the service ``policy.json`` files as does horizon. Ultimately
|
||||
the hard-coded RBAC rules might be expressed as policy rules in many cases,
|
||||
allowing greater configuration flexibility (for instance, restricting access
|
||||
to a resource to the user that created it and not the projec/tenant). This
|
||||
to a resource to the user that created it and not the project/tenant). This
|
||||
will make it easier to keep searchlight deployments in sync with the rules
|
||||
deployed with each service.
|
||||
|
||||
|
|
|
@ -118,7 +118,7 @@ the "fine" level we will be considering.
|
|||
|
||||
Since we are already using bulk commands for Elasticsearch re-indexing, we will
|
||||
place all of the Elasticsearch re-indexing into a single thread. Considering
|
||||
that this iwll be I/O bound on Elasticsearch's side, There does not appear
|
||||
that this will be I/O bound on Elasticsearch's side, There does not appear
|
||||
to be any advantage of doing an Elasticsearch re-indexing for each resource type
|
||||
in a separate thread.
|
||||
|
||||
|
@ -133,7 +133,7 @@ index, will be placed in a single worker in the thread pool.
|
|||
There may be a large number of plugins used with Searchlight. If each plugin
|
||||
has its own thread, we may be using a lot of threads. Instead of having a single
|
||||
thread map to a single plugin, we will use a thread pool. This will keep the
|
||||
number of threads to a managable level while still allowing for an appropriate
|
||||
number of threads to a manageable level while still allowing for an appropriate
|
||||
level of asynchronous re-indexing. The size of the thread pool can be changed
|
||||
through a configuration option.
|
||||
|
||||
|
|
|
@ -124,8 +124,8 @@ plugin, any filtering of notifications to be actually transmitted from
|
|||
Searchlight to Zaqar can further be handled there. Leaving the error handling
|
||||
to the plugin makes sense because some consumers may care about lost
|
||||
notifications while others may not. For example, a mail program displays
|
||||
messages as they arrive, but occassionally the VPN goes down, or there is no
|
||||
wireless connectity or other problem. The mail reader then may on reconnect
|
||||
messages as they arrive, but occasionally the VPN goes down, or there is no
|
||||
wireless connectivity or other problem. The mail reader then may on reconnect
|
||||
just issue a mail-synch. It is in this vein that we leave notification
|
||||
handling to the plugin and its associated consumer and its end-user API.
|
||||
Essentially re-try behavior, re-synch behavior are all left to the
|
||||
|
|
|
@ -19,7 +19,7 @@ Ironic plugin
|
|||
https://blueprints.launchpad.net/searchlight/+spec/ironic-plugin
|
||||
|
||||
This spec is proposed to add ironic plugin for Searchlight. Ironic is OpenStack
|
||||
baremetal service. Plugin should support these baremetal resourses: nodes
|
||||
baremetal service. Plugin should support these baremetal resources: nodes
|
||||
(OS::Ironic::Node), ports (OS::Ironic::Port) and chassis (OS::Ironic::Chassis).
|
||||
|
||||
Problem Description
|
||||
|
|
|
@ -34,7 +34,7 @@ Some notes about using this template:
|
|||
are preferred. http://asciiflow.com/ is a very nice tool to assist with
|
||||
making ascii diagrams. blockdiag is another tool. These are described below.
|
||||
If you require an image (screenshot) for your BP, attaching that to the BP
|
||||
and checking it in is also accepted. However, text representations are prefered.
|
||||
and checking it in is also accepted. However, text representations are preferred.
|
||||
|
||||
* Diagram examples
|
||||
|
||||
|
@ -208,7 +208,7 @@ Tacker's attribute map facility should have the following:
|
|||
inconsistent parameters supplied to the method, or when an
|
||||
instance is not in an appropriate state for the request to
|
||||
succeed. Errors caused by syntactic problems covered by the JSON
|
||||
schema defintion do not need to be included.
|
||||
schema definition do not need to be included.
|
||||
|
||||
* URL for the resource
|
||||
|
||||
|
|
Loading…
Reference in New Issue