olopez32 / ganeti

Automatically exported from code.google.com/p/ganeti
0 stars 0 forks source link

Enable disk add with --no-wait-for-sync for shutdown instances #1010

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What software version are you running? Please provide the output of "gnt-
cluster --version", "gnt-cluster version", and "hspace --version".

root@wrn-vm1:~# gnt-cluster --version
gnt-cluster (ganeti v2.11.6) 2.11.6
root@wrn-vm1:~# gnt-cluster version
Software version: 2.11.6
Internode protocol: 2110000
Configuration format: 2110000
OS api version: 20
Export interface: 0
VCS version: (ganeti) version v2.11.6
root@wrn-vm1:~# hspace --version
hspace (ganeti) version v2.11.6
compiled with ghc 7.4
running on linux x86_64

What distribution are you using?

Debian Wheezy

What steps will reproduce the problem?

This is a shutdown drbd instance with a single disk.

root@wrn-vm1:~# gnt-instance modify --disk add:size=50G --no-wait-for-sync 
ardb.int.example.net
Failure: prerequisites not met for this operation:
error type: wrong_input, error details:
Can't add a disk to an instance with deactivated disks and --no-wait-for-sync 
given.

So I was forced to do:

root@wrn-vm1:~# gnt-instance modify --disk add:size=50G ardb.int.example.net
Mon Dec 15 10:22:57 2014  - INFO: Waiting for instance ardb.int.example.net to 
sync disks
Mon Dec 15 10:22:59 2014  - INFO: - device disk/1:  2.10% done, 15m 12s 
remaining (estimated)
... etc, waiting 15 minutes for command to complete

What is the expected output? What do you see instead?

I expected that "--no-wait-for-sync" would add the disk and return immediately, 
leaving drbd to sync in the background.

Please provide any additional information below.

I don't see anything in the manpage which says that --no-wait-for-sync cannot 
be used on shutdown instances.

       The  --disk add:size=*SIZE*,[options..]  option  adds  a  disk  to  the
       instance, and --disk *N*:add:size=*SIZE*,[options..] will add a disk to
       the  the  instance  at a specific index.  The available options are the
       same as in the add command(spindles,  mode,  name,  vg,  metavg).   Per
       default, gnt-instance waits for the disk mirror to sync.  If you do not
       want this behavior, use the --no-wait-for-sync option.

And in the case of converting -t plain to -t drbd, which also supports 
--no-wait-for-sync,  the instance *must* be shutdown.

Partial workaround is to use the "--submit" option; however the instance still 
cannot be restarted until the sync is complete.

Original issue reported on code.google.com by bcandler...@googlemail.com on 15 Dec 2014 at 10:33

GoogleCodeExporter commented 9 years ago
We do this because of an internal restriction - we track whether disks are 
active or not via a single flag. The newly added disk must be active to 
synchronize, while already existing disks have been deactivated during 
shutdown, or not activated at all. Having the disks both active and inactive 
violates assumptions and causes errors across the codebase, so we force 
ourselves into consistency in the only way that still preserves redundancy - 
waiting for the sync to complete before shutting down the disk.

This is something that could be improved in a newer Ganeti version where disks 
are separate objects, but there is no possible way we can port this to 2.11. 
I'm keeping this bug around, but setting the version to 2.14. Let me know if 
anything else is needed - perhaps a manpage update?

Original comment by r...@google.com on 17 Dec 2014 at 12:40

GoogleCodeExporter commented 9 years ago
I note that --no-wait-for-sync can be used on with gnt-instance modify -t drbd; 
maybe it's because *all* the disks are activated in that instance?

If it's OK to activate the disks on a shutdown instance, maybe a workaround is 
to use "gnt-instance activate-disks" before adding the new disk?

Otherwise, yes I think a documentation update is in order. Currently it just 
says:

"Per default, gnt-instance waits for the disk
mirror to sync.
If you do not want this behavior, use the ``--no-wait-for-sync`` option."

so add a note explaining under what circumstances this can be done. I guess 
--hotplug on a running instance is one of them?

Original comment by bcandler...@googlemail.com on 24 Dec 2014 at 9:40