LGTM, Thanks for tracing this down, and cleaning it up! On Fri, May 6, 2016 at 3:35 PM, 'Brian Foley' via ganeti-devel < [email protected]> wrote:
> As reported in 1177, the option is --new-node-certificates not > --renew-node-certificates. > > While here, fix a few other miscellaneous docs typos. > > Signed-off-by: Brian Foley <[email protected]> > --- > NEWS | 2 +- > doc/design-2.0.rst | 6 +++--- > doc/design-2.1.rst | 6 +++--- > doc/design-2.2.rst | 10 +++++----- > doc/design-query2.rst | 2 +- > 5 files changed, 13 insertions(+), 13 deletions(-) > > diff --git a/NEWS b/NEWS > index f212ca2..123bc99 100644 > --- a/NEWS > +++ b/NEWS > @@ -1347,7 +1347,7 @@ Incompatible/important changes > code of ``gnt-cluster verify``. > - RPC security got enhanced by using different client SSL certificates > for each node. In this context 'gnt-cluster renew-crypto' got a new > - option '--renew-node-certificates', which renews the client > + option '--new-node-certificates', which renews the client > certificates of all nodes. After a cluster upgrade from pre-2.11, run > this to create client certificates and activate this feature. > > diff --git a/doc/design-2.0.rst b/doc/design-2.0.rst > index 6bff30a..7ff6daf 100644 > --- a/doc/design-2.0.rst > +++ b/doc/design-2.0.rst > @@ -1711,13 +1711,13 @@ Design > The Ganeti RAPI is implemented as independent daemon, running on the > same node with the same permission level as Ganeti master > daemon. Communication is done through the LUXI library to the master > -daemon. In order to keep communication asynchronous RAPI processes two > +daemon. In order to keep communication asynchronous, RAPI processes two > types of client requests: > > - queries: server is able to answer immediately > - job submission: some time is required for a useful response > > -In the query case requested data send back to client in the HTTP > +In the query case requested data is sent back to client in the HTTP > response body. Typical examples of queries would be: list of nodes, > instances, cluster info, etc. > > @@ -1725,7 +1725,7 @@ In the case of job submission, the client receive a > job ID, the > identifier which allows one to query the job progress in the job queue > (see `Job Queue`_). > > -Internally, each exported object has an version identifier, which is > +Internally, each exported object has a version identifier, which is > used as a state identifier in the HTTP header E-Tag field for > requests/responses to avoid race conditions. > > diff --git a/doc/design-2.1.rst b/doc/design-2.1.rst > index 0251fef..a1df225 100644 > --- a/doc/design-2.1.rst > +++ b/doc/design-2.1.rst > @@ -68,8 +68,8 @@ all the curent VG/FileBased operations to it. > > Note that while we model both LVM PVs and LVM VGs, the framework will > **not** model any relationship between the different types. In other > -words, we don't model neither inheritances nor stacking, since this is > -too complex for our needs. While a ``vgreduce`` operation on a LVM VG > +words, we model neither inheritances nor stacking, since this is too > +complex for our needs. While a ``vgreduce`` operation on a LVM VG > could actually remove a PV from it, this will not be handled at the > framework level, but at individual operation level. The goal is that > this is a lightweight framework, for abstracting the different storage > @@ -389,7 +389,7 @@ Current situation > Currently there's no easy way to merge two or more clusters together. > But in order to optimize resources this is a needed missing piece. The > goal of this design doc is to come up with a easy to use solution which > -allows you to merge two or more cluster together. > +allows you to merge two or more clusters together. > > Initial contact > +++++++++++++++ > diff --git a/doc/design-2.2.rst b/doc/design-2.2.rst > index 5af014a..df3d53f 100644 > --- a/doc/design-2.2.rst > +++ b/doc/design-2.2.rst > @@ -61,10 +61,10 @@ Wait for job change > +++++++++++++++++++ > > The REQ_WAIT_FOR_JOB_CHANGE luxi operation makes the relevant client > -thread block on its job for a relative long time. This is another easy > -way to exhaust the 16 client threads, and a place where clients often > -time out, moreover this operation is negative for the job queue lock > -contention (see below). > +thread block on its job for a relatively long time. This is another > +easy way to exhaust the 16 client threads, and a place where clients > +often time out, moreover this operation is negative for the job queue > +lock contention (see below). > > Job Queue lock > ++++++++++++++ > @@ -152,7 +152,7 @@ The REQ_WAIT_FOR_JOB_CHANGE luxi request is changed to > be > subscription-based, so that the executing thread doesn't have to be > waiting for the changes to arrive. Threads producing messages (job queue > executors) will make sure that when there is a change another thread is > -awaken and delivers it to the waiting clients. This can be either a > +awakened and delivers it to the waiting clients. This can be either a > dedicated "wait for job changes" thread or pool, or one of the client > workers, depending on what's easier to implement. In either case the > main asyncore thread will only be involved in pushing of the actual > diff --git a/doc/design-query2.rst b/doc/design-query2.rst > index 4c7b52d..1319f30 100644 > --- a/doc/design-query2.rst > +++ b/doc/design-query2.rst > @@ -131,7 +131,7 @@ The request is a dictionary with the following entries: > > ["|", ["=", "name", "node1"], ["=", "name", "node2"], …] > > - Filters consist of S-expressions (``["operator", <operants…>]``) and > + Filters consist of S-expressions (``["operator", <operands…>]``) and > extensions will be made in the future to allow for more operators and > fields. Such extensions might include a Python-style "in" operator, > but for simplicity only "=" is supported in this implementation. > -- > 2.8.0.rc3.226.g39d4020 > >
