LGTM, thanks On Mon, 27 Apr 2015 at 13:01 'Klaus Aehlig' via ganeti-devel < [email protected]> wrote:
> As it turns out, simply iterating the steps that hail does > is fast enough for shared storage, so that we can have accurate > predictions with hspace. > > Signed-off-by: Klaus Aehlig <[email protected]> > --- > doc/design-shared-storage-redundancy.rst | 11 +++++------ > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/doc/design-shared-storage-redundancy.rst > b/doc/design-shared-storage-redundancy.rst > index a5b9ade..0347ef2 100644 > --- a/doc/design-shared-storage-redundancy.rst > +++ b/doc/design-shared-storage-redundancy.rst > @@ -65,12 +65,11 @@ Modifications to existing tools > on the next move, it will filter out those moves that lead from a > shared storage N+1 redundant configuration into one that isn't. > > -- ``hspace`` computing the capacity for DRBD instances will be unchanged. > - For shared storage instances, however, it will first evacuate one node > - and then compute capacity as normal pretending that node was offline. > - While this technically deviates from interatively doing what hail does, > - it should still give a reasonable estimate of the cluster capacity > without > - significantly increasing the algorithmic complexity. > +- ``hspace`` computing the capacity for DRBD instances will be unchanged; > + In particular, the options ``--accept-exisiting`` and > ``--independent-groups`` > + will continue to work. For shared storage instances, however, will > strictly > + iterate over the same allocation step as hail does. > + > > Other modifications related to opportunistic locking > ---------------------------------------------------- > -- > 2.2.0.rc0.207.ga3a616c > >
