diff --git a/specs/mitaka/per-resource-policy.rst b/specs/mitaka/per-resource-policy.rst index 0848320..4751afb 100644 --- a/specs/mitaka/per-resource-policy.rst +++ b/specs/mitaka/per-resource-policy.rst @@ -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. diff --git a/specs/newton/index-performance-enhancement.rst b/specs/newton/index-performance-enhancement.rst index 203a80c..22d90ae 100644 --- a/specs/newton/index-performance-enhancement.rst +++ b/specs/newton/index-performance-enhancement.rst @@ -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. diff --git a/specs/newton/notification-forwarding.rst b/specs/newton/notification-forwarding.rst index 61ea46e..3612931 100644 --- a/specs/newton/notification-forwarding.rst +++ b/specs/newton/notification-forwarding.rst @@ -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 diff --git a/specs/ocata/ironic-plugin.rst b/specs/ocata/ironic-plugin.rst index 45f8aa8..2b813f5 100644 --- a/specs/ocata/ironic-plugin.rst +++ b/specs/ocata/ironic-plugin.rst @@ -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 diff --git a/specs/template.rst b/specs/template.rst index a3526be..cb62d7c 100644 --- a/specs/template.rst +++ b/specs/template.rst @@ -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