Update documentation of gnt-node {add,remove,modify}
[ganeti-github.git] / man / gnt-node.rst
1 gnt-node(8) Ganeti | Version @GANETI_VERSION@
2 =============================================
3
4 Name
5 ----
6
7 gnt-node - Node administration
8
9 Synopsis
10 --------
11
12 **gnt-node** {command} [arguments...]
13
14 DESCRIPTION
15 -----------
16
17 The **gnt-node** is used for managing the (physical) nodes in the
18 Ganeti system.
19
20 COMMANDS
21 --------
22
23 ADD
24 ~~~
25
26 | **add** [\--readd] [{-s|\--secondary-ip} *secondary\_ip*]
27 | [{-g|\--node-group} *nodegroup*]
28 | [\--master-capable=``yes|no``] [\--vm-capable=``yes|no``]
29 | [\--node-parameters *ndparams*]
30 | [\--disk-state *diskstate*]
31 | [\--hypervisor-state *hvstate*]
32 | [\--no-node-setup]
33 | [\--verbose] | [\--debug]
34 | {*nodename*}
35
36 Adds the given node to the cluster.
37
38 This command is used to join a new node to the cluster. You will
39 have to provide credentials to ssh as root to the node to be added.
40 Forwardig of an ssh agent (the ``-A`` option of ssh) works, if an
41 appropriate authorized key is set up on the node to be added. If
42 the other node allows password authentication for root, another
43 way of providing credentials is to provide the root password once
44 asked for it. The command needs to be run on the Ganeti master.
45
46 Note that the command is potentially destructive, as it will
47 forcibly join the specified host to the cluster, not paying attention
48 to its current status (it could be already in a cluster, etc.)
49
50 The ``-s (--secondary-ip)`` is used in dual-home clusters and
51 specifies the new node's IP in the secondary network. See the
52 discussion in **gnt-cluster**\(8) for more information.
53
54 In case you're readding a node after hardware failure, you can use
55 the ``--readd`` parameter. In this case, you don't need to pass the
56 secondary IP again, it will be reused from the cluster. Also, the
57 drained and offline flags of the node will be cleared before
58 re-adding it. Note that even for readded nodes, a new SSH key is
59 generated and distributed and previous Ganeti keys are removed
60 from the machine.
61
62 The ``-g (--node-group)`` option is used to add the new node into a
63 specific node group, specified by UUID or name. If only one node group
64 exists you can skip this option, otherwise it's mandatory.
65
66 The ``--no-node-setup`` option that used to prevent Ganeti from performing
67 the initial SSH setup on the new node is no longer valid. Instead,
68 Ganeti consideres the ``modify ssh setup`` configuration parameter
69 (which is set using ``--no-ssh-init`` during cluster initialization)
70 to determine whether or not to do the SSH setup on a new node or not.
71 If this parameter is set to ``False``, Ganeti will not touch the SSH
72 keys or the ``authorized_keys`` file of the node at all. Using this option,
73 it lies in the administrators responsibility to ensure SSH connectivity
74 between the hosts by other means.
75
76 The ``vm_capable``, ``master_capable``, ``ndparams``, ``diskstate`` and
77 ``hvstate`` options are described in **ganeti**\(7), and are used to set
78 the properties of the new node.
79
80 The command performs some operations that change the state of the master
81 and the new node, like copying certificates and starting the node daemon
82 on the new node, or updating ``/etc/hosts`` on the master node.  If the
83 command fails at a later stage, it doesn't undo such changes.  This
84 should not be a problem, as a successful run of ``gnt-node add`` will
85 bring everything back in sync.
86
87 If the node was previously part of another cluster and still has daemons
88 running, the ``node-cleanup`` tool can be run on the machine to be added
89 to clean remains of the previous cluster from the node.
90
91 The options ``--verbose`` and ``--debug`` control the log level of the
92 operation, in particular the one of the underlying SSH calls that
93 Ganeti makes when adding a node.
94
95 Example::
96
97     # gnt-node add node5.example.com
98     # gnt-node add -s 192.0.2.5 node5.example.com
99     # gnt-node add -g group2 -s 192.0.2.9 node9.group2.example.com
100
101
102 EVACUATE
103 ~~~~~~~~
104
105 | **evacuate** [-f] [\--early-release] [\--submit] [\--print-jobid]
106 | [{-I|\--iallocator} *NAME* \| {-n|\--new-secondary} *destination\_node*]
107 | [--ignore-soft-errors]
108 | [{-p|\--primary-only} \| {-s|\--secondary-only} ]
109 |  {*node*}
110
111 This command will move instances away from the given node. If
112 ``--primary-only`` is given, only primary instances are evacuated, with
113 ``--secondary-only`` only secondaries. If neither is given, all
114 instances are evacuated. It works only for instances having a drbd disk
115 template.
116
117 The new location for the instances can be specified in two ways:
118
119 - as a single node for all instances, via the ``-n (--new-secondary)``
120   option
121
122 - or via the ``-I (--iallocator)`` option, giving a script name as
123   parameter (or ``.`` to use the default allocator), so each instance
124   will be in turn placed on the (per the script) optimal node
125
126 The ``--early-release`` changes the code so that the old storage on
127 node being evacuated is removed early (before the resync is
128 completed) and the internal Ganeti locks are also released for both
129 the current secondary and the new secondary, thus allowing more
130 parallelism in the cluster operation. This should be used only when
131 recovering from a disk failure on the current secondary (thus the
132 old storage is already broken) or when the storage on the primary
133 node is known to be fine (thus we won't need the old storage for
134 potential recovery).
135
136 Note that this command is equivalent to using per-instance commands for
137 each affected instance individually:
138
139 - ``--primary-only`` is equivalent to performing ``gnt-instance
140   migrate`` for every primary instance running on the node that can be
141   migrated and ``gnt-instance failover`` for every primary instance that
142   cannot be migrated.
143 - ``--secondary-only`` is equivalent to ``gnt-instance replace-disks``
144   in secondary node change mode (``--new-secondary``) for every DRBD
145   instance that the node is a secondary for.
146 - when neither of the above is done a combination of the two cases is run
147
148 Note that the iallocator currently only considers disk information of
149 the default disk template, even if the instance's disk templates differ
150 from that.
151
152 The ``--ignore-soft-errors`` option is passed through to the allocator.
153
154 See **ganeti**\(7) for a description of ``--submit`` and other common
155 options.
156
157 Example::
158
159     # gnt-node evacuate -I hail node3.example.com
160
161 Note that, due to an issue with the iallocator interface, evacuation of
162 all instances at once is not yet implemented. Full evacuation can
163 currently be achieved by sequentially evacuating primaries and
164 secondaries.
165 ::
166
167     # gnt-node evacuate -p node3.example.com
168     # gnt-node evacuate -s node3.example.com
169
170
171 FAILOVER
172 ~~~~~~~~
173
174 **failover** [-f] [\--ignore-consistency] {*node*}
175
176 This command will fail over all instances having the given node as
177 primary to their secondary nodes. This works only for instances having
178 a drbd disk template.
179
180 Note that failover will stop any running instances on the given node and
181 restart them again on the new primary.
182 See also FAILOVER in **gnt-instance**\(8).
183
184 Normally the failover will check the consistency of the disks before
185 failing over the instance. If you are trying to migrate instances off
186 a dead node, this will fail. Use the ``--ignore-consistency`` option
187 for this purpose.
188
189 Example::
190
191     # gnt-node failover node1.example.com
192
193
194 INFO
195 ~~~~
196
197 **info** [*node*...]
198
199 Show detailed information about the nodes in the cluster. If you
200 don't give any arguments, all nodes will be shows, otherwise the
201 output will be restricted to the given names.
202
203 LIST
204 ~~~~
205
206 | **list**
207 | [\--no-headers] [\--separator=*SEPARATOR*]
208 | [\--units=*UNITS*] [-v] [{-o|\--output} *[+]FIELD,...*]
209 | [\--filter]
210 | [node...]
211
212 Lists the nodes in the cluster.
213
214 The ``--no-headers`` option will skip the initial header line. The
215 ``--separator`` option takes an argument which denotes what will be
216 used between the output fields. Both these options are to help
217 scripting.
218
219 The units used to display the numeric values in the output varies,
220 depending on the options given. By default, the values will be
221 formatted in the most appropriate unit. If the ``--separator``
222 option is given, then the values are shown in mebibytes to allow
223 parsing by scripts. In both cases, the ``--units`` option can be
224 used to enforce a given output unit.
225
226 Queries of nodes will be done in parallel with any running jobs. This might
227 give inconsistent results for the free disk/memory.
228
229 The ``-v`` option activates verbose mode, which changes the display of
230 special field states (see **ganeti**\(7)).
231
232 The ``-o (--output)`` option takes a comma-separated list of output
233 fields. The available fields and their meaning are:
234
235 @QUERY_FIELDS_NODE@
236
237 If the value of the option starts with the character ``+``, the new
238 fields will be added to the default list. This allows one to quickly
239 see the default list plus a few other fields, instead of retyping
240 the entire list of fields.
241
242 Note that some of these fields are known from the configuration of the
243 cluster (e.g. ``name``, ``pinst``, ``sinst``, ``pip``, ``sip``) and thus
244 the master does not need to contact the node for this data (making the
245 listing fast if only fields from this set are selected), whereas the
246 other fields are "live" fields and require a query to the cluster nodes.
247
248 Depending on the virtualization type and implementation details, the
249 ``mtotal``, ``mnode`` and ``mfree`` fields may have slightly varying
250 meanings. For example, some solutions share the node memory with the
251 pool of memory used for instances (KVM), whereas others have separate
252 memory for the node and for the instances (Xen).
253
254 Note that the field 'dtotal' and 'dfree' refer to the storage type
255 that is defined by the default disk template. The default disk template
256 is the first on in the list of cluster-wide enabled disk templates and
257 can be set with ``gnt-cluster modify``. Currently, only the disk
258 templates 'plain', 'drbd', 'file', and 'sharedfile' support storage
259 reporting, for all others '0' is displayed.
260
261 If exactly one argument is given and it appears to be a query filter
262 (see **ganeti**\(7)), the query result is filtered accordingly. For
263 ambiguous cases (e.g. a single field name as a filter) the ``--filter``
264 (``-F``) option forces the argument to be treated as a filter (e.g.
265 ``gnt-node list -F master_candidate``).
266
267 If no node names are given, then all nodes are queried. Otherwise,
268 only the given nodes will be listed.
269
270
271 LIST-DRBD
272 ~~~~~~~~~
273
274 **list-drbd** [\--no-headers] [\--separator=*SEPARATOR*] node
275
276 Lists the mapping of DRBD minors for a given node. This outputs a static
277 list of fields (it doesn't accept the ``--output`` option), as follows:
278
279 ``Node``
280   The (full) name of the node we are querying
281 ``Minor``
282   The DRBD minor
283 ``Instance``
284   The instance the DRBD minor belongs to
285 ``Disk``
286   The disk index that the DRBD minor belongs to
287 ``Role``
288   Either ``primary`` or ``secondary``, denoting the role of the node for
289   the instance (note: this is not the live status of the DRBD device,
290   but the configuration value)
291 ``PeerNode``
292   The node that the minor is connected to on the other end
293
294 This command can be used as a reverse lookup (from node and minor) to a
295 given instance, which can be useful when debugging DRBD issues.
296
297 Note that this command queries Ganeti via **ganeti-confd**\(8), so
298 it won't be available if support for ``confd`` has not been enabled at
299 build time; furthermore, in Ganeti 2.6 this is only available via the
300 Haskell version of confd (again selected at build time).
301
302 LIST-FIELDS
303 ~~~~~~~~~~~
304
305 **list-fields** [field...]
306
307 Lists available fields for nodes.
308
309
310 MIGRATE
311 ~~~~~~~
312
313 | **migrate** [-f] [\--non-live] [\--migration-mode=live\|non-live]
314 | [\--ignore-ipolicy] [\--submit] [\--print-jobid] {*node*}
315
316 This command will migrate all instances having the given node as
317 primary to their secondary nodes. This works only for instances
318 having a drbd disk template.
319
320 As for the **gnt-instance migrate** command, the options
321 ``--no-live``, ``--migration-mode`` and ``--no-runtime-changes``
322 can be given to influence the migration type.
323
324 If ``--ignore-ipolicy`` is given any instance policy violations
325 occurring during this operation are ignored.
326
327 See **ganeti**\(7) for a description of ``--submit`` and other common
328 options.
329
330 Example::
331
332     # gnt-node migrate node1.example.com
333
334
335 MODIFY
336 ~~~~~~
337
338 | **modify** [-f] [\--submit] [\--print-jobid]
339 | [{-C|\--master-candidate} ``yes|no``]
340 | [{-D|\--drained} ``yes|no``] [{-O|\--offline} ``yes|no``]
341 | [\--master-capable=``yes|no``] [\--vm-capable=``yes|no``] [\--auto-promote]
342 | [{-s|\--secondary-ip} *secondary_ip*]
343 | [\--node-parameters *ndparams*]
344 | [\--node-powered=``yes|no``]
345 | [\--hypervisor-state *hvstate*]
346 | [\--disk-state *diskstate*]
347 | [\--verbose] [\--debug]
348 | {*node*}
349
350 This command changes the role of the node. Each options takes
351 either a literal yes or no, and only one option should be given as
352 yes. The meaning of the roles and flags are described in the
353 manpage **ganeti**\(7).
354
355 The option ``--node-powered`` can be used to modify state-of-record if
356 it doesn't reflect the reality anymore.
357
358 In case a node is demoted from the master candidate role, the
359 operation will be refused unless you pass the ``--auto-promote``
360 option. This option will cause the operation to lock all cluster nodes
361 (thus it will not be able to run in parallel with most other jobs),
362 but it allows automated maintenance of the cluster candidate pool. If
363 locking all cluster node is too expensive, another option is to
364 promote manually another node to master candidate before demoting the
365 current one.
366
367 Example (setting a node offline, which will demote it from master
368 candidate role if is in that role)::
369
370     # gnt-node modify --offline=yes node1.example.com
371
372 The ``-s (--secondary-ip)`` option can be used to change the node's
373 secondary ip. No drbd instances can be running on the node, while this
374 operation is taking place. Remember that the secondary ip must be
375 reachable from the master secondary ip, when being changed, so be sure
376 that the node has the new IP already configured and active. In order to
377 convert a cluster from single homed to multi-homed or vice versa
378 ``--force`` is needed as well, and the target node for the first change
379 must be the master.
380
381 The options ``--verbose`` and ``--debug`` control the log level of the
382 operation, in particular the one of the underlying SSH calls that
383 Ganeti makes when modifying some parameters a node (e.g. promoting
384 or demoting a node to or from 'master candidate' status).
385
386 See **ganeti**\(7) for a description of ``--submit`` and other common
387 options.
388
389 Example (setting the node back to online and master candidate)::
390
391     # gnt-node modify --offline=no --master-candidate=yes node1.example.com
392
393
394 REMOVE
395 ~~~~~~
396
397 **remove** [\--verbose] [\--debug] {*nodename*}
398
399 Removes a node from the cluster. Instances must be removed or
400 migrated to another cluster before.
401
402 The options ``--verbose`` and ``--debug`` control the log level of the
403 operation, in particular the one of the underlying SSH calls that
404 Ganeti makes when removing a node.
405
406
407 Example::
408
409     # gnt-node remove node5.example.com
410
411
412 VOLUMES
413 ~~~~~~~
414
415 | **volumes** [\--no-headers] [\--human-readable]
416 | [\--separator=*SEPARATOR*] [{-o|\--output} *FIELDS*]
417 | [*node*...]
418
419 Lists all logical volumes and their physical disks from the node(s)
420 provided.
421
422 The ``--no-headers`` option will skip the initial header line. The
423 ``--separator`` option takes an argument which denotes what will be
424 used between the output fields. Both these options are to help
425 scripting.
426
427 The units used to display the numeric values in the output varies,
428 depending on the options given. By default, the values will be
429 formatted in the most appropriate unit. If the ``--separator``
430 option is given, then the values are shown in mebibytes to allow
431 parsing by scripts. In both cases, the ``--units`` option can be
432 used to enforce a given output unit.
433
434 The ``-o (--output)`` option takes a comma-separated list of output
435 fields. The available fields and their meaning are:
436
437 node
438     the node name on which the volume exists
439
440 phys
441     the physical drive (on which the LVM physical volume lives)
442
443 vg
444     the volume group name
445
446 name
447     the logical volume name
448
449 size
450     the logical volume size
451
452 instance
453     The name of the instance to which this volume belongs, or (in case
454     it's an orphan volume) the character "-"
455
456
457 Example::
458
459     # gnt-node volumes node5.example.com
460     Node              PhysDev   VG    Name                                 Size Instance
461     node1.example.com /dev/hdc1 xenvg instance1.example.com-sda_11000.meta 128  instance1.example.com
462     node1.example.com /dev/hdc1 xenvg instance1.example.com-sda_11001.data 256  instance1.example.com
463
464
465 LIST-STORAGE
466 ~~~~~~~~~~~~
467
468 | **list-storage** [\--no-headers] [\--human-readable]
469 | [\--separator=*SEPARATOR*] [\--storage-type=*STORAGE\_TYPE*]
470 | [{-o|\--output} *FIELDS*]
471 | [*node*...]
472
473 Lists the available storage units and their details for the given
474 node(s).
475
476 The ``--no-headers`` option will skip the initial header line. The
477 ``--separator`` option takes an argument which denotes what will be
478 used between the output fields. Both these options are to help
479 scripting.
480
481 The units used to display the numeric values in the output varies,
482 depending on the options given. By default, the values will be
483 formatted in the most appropriate unit. If the ``--separator``
484 option is given, then the values are shown in mebibytes to allow
485 parsing by scripts. In both cases, the ``--units`` option can be
486 used to enforce a given output unit.
487
488 The ``--storage-type`` option can be used to choose a storage unit
489 type. Possible choices are lvm-pv, lvm-vg, file, sharedfile and gluster.
490
491 The ``-o (--output)`` option takes a comma-separated list of output
492 fields. The available fields and their meaning are:
493
494 node
495     the node name on which the volume exists
496
497 type
498     the type of the storage unit (currently just what is passed in via
499     ``--storage-type``)
500
501 name
502     the path/identifier of the storage unit
503
504 size
505     total size of the unit; for the file type see a note below
506
507 used
508     used space in the unit; for the file type see a note below
509
510 free
511     available disk space
512
513 allocatable
514     whether we the unit is available for allocation (only lvm-pv can
515     change this setting, the other types always report true)
516
517
518 Note that for the "file" type, the total disk space might not equal
519 to the sum of used and free, due to the method Ganeti uses to
520 compute each of them. The total and free values are computed as the
521 total and free space values for the filesystem to which the
522 directory belongs, but the used space is computed from the used
523 space under that directory *only*, which might not be necessarily
524 the root of the filesystem, and as such there could be files
525 outside the file storage directory using disk space and causing a
526 mismatch in the values.
527
528 Example::
529
530     node1# gnt-node list-storage node2
531     Node  Type   Name        Size Used   Free Allocatable
532     node2 lvm-pv /dev/sda7 673.8G 1.5G 672.3G Y
533     node2 lvm-pv /dev/sdb1 698.6G   0M 698.6G Y
534
535
536 MODIFY-STORAGE
537 ~~~~~~~~~~~~~~
538
539 | **modify-storage** [\--allocatable={yes|no}] [\--submit] [\--print-jobid]
540 | {*node*} {*storage-type*} {*volume-name*}
541
542 Modifies storage volumes on a node. Only LVM physical volumes can
543 be modified at the moment. They have a storage type of "lvm-pv".
544
545 Example::
546
547     # gnt-node modify-storage --allocatable no node5.example.com lvm-pv /dev/sdb1
548
549
550 REPAIR-STORAGE
551 ~~~~~~~~~~~~~~
552
553 | **repair-storage** [\--ignore-consistency] ]\--submit]
554 | {*node*} {*storage-type*} {*volume-name*}
555
556 Repairs a storage volume on a node. Only LVM volume groups can be
557 repaired at this time. They have the storage type "lvm-vg".
558
559 On LVM volume groups, **repair-storage** runs ``vgreduce
560 --removemissing``.
561
562
563
564 **Caution:** Running this command can lead to data loss. Use it with
565 care.
566
567 The ``--ignore-consistency`` option will ignore any inconsistent
568 disks (on the nodes paired with this one). Use of this option is
569 most likely to lead to data-loss.
570
571 Example::
572
573     # gnt-node repair-storage node5.example.com lvm-vg xenvg
574
575
576 POWERCYCLE
577 ~~~~~~~~~~
578
579 **powercycle** [\--yes] [\--force] [\--submit] [\--print-jobid] {*node*}
580
581 This command (tries to) forcefully reboot a node. It is a command
582 that can be used if the node environment is broken, such that the
583 admin can no longer login over SSH, but the Ganeti node daemon is
584 still working.
585
586 Note that this command is not guaranteed to work; it depends on the
587 hypervisor how effective is the reboot attempt. For Linux, this
588 command requires the kernel option ``CONFIG_MAGIC_SYSRQ`` to be
589 enabled.
590
591 The ``--yes`` option can be used to skip confirmation, while the
592 ``--force`` option is needed if the target node is the master
593 node.
594
595 See **ganeti**\(7) for a description of ``--submit`` and other common
596 options.
597
598 POWER
599 ~~~~~
600
601 **power** [``--force``] [``--ignore-status``] [``--all``]
602 [``--power-delay``] on|off|cycle|status [*nodes*]
603
604 This command calls out to out-of-band management to change the power
605 state of given node. With ``status`` you get the power status as reported
606 by the out-of-band management script.
607
608 Note that this command will only work if the out-of-band functionality
609 is configured and enabled on the cluster. If this is not the case,
610 please use the **powercycle** command above.
611
612 Using ``--force`` you skip the confirmation to do the operation.
613 Currently this only has effect on ``off`` and ``cycle``. On those two
614 you can *not* operate on the master. However, the command will provide
615 you with the command to invoke to operate on the master nerver-mind.
616 This is considered harmful and Ganeti does not support the use of it.
617
618 Providing ``--ignore-status`` will ignore the offline=N state of a node
619 and continue with power off.
620
621 ``--power-delay`` specifies the time in seconds (factions allowed)
622 waited between powering on the next node. This is by default 2 seconds
623 but can increased if needed with this option.
624
625 *nodes* are optional. If not provided it will call out for every node in
626 the cluster. Except for the ``off`` and ``cycle`` command where you've
627 to explicit use ``--all`` to select all.
628
629
630 HEALTH
631 ~~~~~~
632
633 **health** [*nodes*]
634
635 This command calls out to out-of-band management to ask for the health status
636 of all or given nodes. The health contains the node name and then the items
637 element with their status in a ``item=status`` manner. Where ``item`` is script
638 specific and ``status`` can be one of ``OK``, ``WARNING``, ``CRITICAL`` or
639 ``UNKNOWN``. Items with status ``WARNING`` or ``CRITICAL`` are logged and
640 annotated in the command line output.
641
642
643 RESTRICTED-COMMAND
644 ~~~~~~~~~~~~~~~~~~
645
646 | **restricted-command** [-M] [\--sync]
647 | { -g *group* *command* | *command* *nodes*... }
648
649 Executes a restricted command on the specified nodes. Restricted commands are
650 not arbitrary, but must reside in
651 ``@SYSCONFDIR@/ganeti/restricted-commands`` on a node, either as a regular
652 file or as a symlink. The directory must be owned by root and not be
653 world- or group-writable. If a command fails verification or otherwise
654 fails to start, the node daemon log must be consulted for more detailed
655 information.
656
657 Example for running a command on two nodes::
658
659     # gnt-node restricted-command mycommand \
660       node1.example.com node2.example.com
661
662 The ``-g`` option can be used to run a command only on a specific node
663 group, e.g.::
664
665     # gnt-node restricted-command -g default mycommand
666
667 The ``-M`` option can be used to prepend the node name to all command
668 output lines. ``--sync`` forces the opcode to acquire the node lock(s)
669 in exclusive mode.
670
671 REPAIR-COMMAND
672 ~~~~~~~~~~~~~~~~~~
673
674 | **repair-command** { --input *input* } *command* *node*
675
676 Executes a repair command. Repair commands reside in
677 ``@SYSCONFDIR@/ganeti/node-repair-commands`` on a node, either as a regular
678 file or as a symlink. The directory must be owned by root and not be
679 world- or group-writable. If a command fails verification or otherwise
680 fails to start, the node daemon log must be consulted for more detailed
681 information.
682
683 Example for running a command::
684
685     # gnt-node repair-command --input "input string" \
686       mycommand node.example.com
687
688 Tags
689 ~~~~
690
691 ADD-TAGS
692 ^^^^^^^^
693
694 **add-tags** [\--from *file*] {*nodename*} {*tag*...}
695
696 Add tags to the given node. If any of the tags contains invalid
697 characters, the entire operation will abort.
698
699 If the ``--from`` option is given, the list of tags will be
700 extended with the contents of that file (each line becomes a tag).
701 In this case, there is not need to pass tags on the command line
702 (if you do, both sources will be used). A file name of - will be
703 interpreted as stdin.
704
705 LIST-TAGS
706 ^^^^^^^^^
707
708 **list-tags** {*nodename*}
709
710 List the tags of the given node.
711
712 REMOVE-TAGS
713 ^^^^^^^^^^^
714
715 **remove-tags** [\--from *file*] {*nodename*} {*tag*...}
716
717 Remove tags from the given node. If any of the tags are not
718 existing on the node, the entire operation will abort.
719
720 If the ``--from`` option is given, the list of tags to be removed will
721 be extended with the contents of that file (each line becomes a tag).
722 In this case, there is not need to pass tags on the command line (if
723 you do, tags from both sources will be removed). A file name of - will
724 be interpreted as stdin.
725
726 .. vim: set textwidth=72 :
727 .. Local Variables:
728 .. mode: rst
729 .. fill-column: 72
730 .. End: