fix typo mistakes
Change-Id: I90b17fd6b15a3a971614486782fec88acc0b6304
This commit is contained in:
parent
074454b636
commit
6088e871c1
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
Loading…
Reference in New Issue