fix typo mistakes

Change-Id: I90b17fd6b15a3a971614486782fec88acc0b6304
This commit is contained in:
MaoyangLiu 2018-12-16 15:39:14 +08:00
parent 074454b636
commit 6088e871c1
2 changed files with 3 additions and 3 deletions

View File

@ -42,7 +42,7 @@ effectively maintain a Swift cluster over time:
have already been initialised.
This forces operators to manually apply changes like adjusting the
partition-power to accomodate for additional storage added to the cluster. This
partition-power to accommodate for additional storage added to the cluster. This
poses great risk since manually editing the rings/builders and syncing them
across the cluster could easily conflict with the swift-proxy charm's native
support for doing this resulting in a broken cluster.
@ -64,7 +64,7 @@ refuse to make changes until the operator has paused the swift-proxy units i.e.
placed them into "maintenance mode" which will shutdown the api services and
block any restarts until the units are resumed. The user will also have the
option to set disable-ring-balance=true if they want check that their changes
have been applied successully (to the builder files) prior to having the rings
have been applied successfully (to the builder files) prior to having the rings
rebuilt and sycned across the cluster.
For the swift-storage charms, where currently one can only add devices but not

View File

@ -49,7 +49,7 @@ software itself and dynamic scaling of the service.
On the scaling side, most if not all, of the ``octavia`` services benefit from
being scaled out proportional to the number of running load balancers and load
balancer life cycle events. Thus it makse sense to co-locate the API, Worker,
balancer life cycle events. Thus it makes sense to co-locate the API, Worker,
Health Manager and Housekeeping Manager daemons in the same charm unit, and
scale by increasing the number of charm units deployed.