cleanup: code lines reodered

lvresize: drop extra sigint handling

yes_no_prompt() now already handles signal checking,
so drop redundant test.

lvresize: inform about ignored args with --use-polices

When --use-polices is specified, all size args are meaningless,
as the resize is based upon policy. So just keep user informed.

lvresize: move and extend resizefs ignoring check

Move check for 'ignoring' --resizefs option and extend check
for some more types.

locking: trace errors from dir creation

monitoring: preserve monitoring status during update

Ignore monitoring during whole update (suspend/resume) of thin-pool.

activation: _lv_active returns 0 on error

We have only 2 users of _lv_active() - one was already checking for ==1
while the other use (_lv_is_active()) could have take '-1' as a sign of having
an LV active. So return 0 and log_debug also the reason while detection
has failed (i.e. in case  --driverload n  - it's kind of expectable,
but might have confused user seeing just <backtrace>).

activation: switch to warning

Since this function does not have a way to return error use correct
reporting level as warning.

libdm: log: remove log_print_bypass_report calls and register new print_log_libdm for libdm during lvm initialization instead

This fixes commit f50d4011cdd3ef38c15b9dea05e73321592d93c2 which
introduced a problem when using older lvm2 code with newer libdm.
In this case, the old LVM didn't recognize new _LOG_BYPASS_REPORT flag
that libdm-report code used. This ended up with no output at all
from libdm where log_print_bypass_report was called because the
_LOG_BYPASS_REPORT was not masked properly in lvm2's print_log fn
which was called as callback function for logging.

With this patch, the lvm2 registers separate print_log_libdm logging
function for libdm instead. The print_log_libdm is exactly the same
as print_log (used throughout lvm2 code) but it checks whether we're
printing common line on output where "common" means not going to stderr,
not a warning and not an error and if we are, it adds the
_LOG_BYPASS_REPORT flag so the log_print goes directly to output, not
to any log report.

So this achieves the same goal as in f50d4011cdd3ef38c15b9dea05e73321592d93c2,
just doing it in a way that newer libdm is still compatible with older
lvm2 code (libdm-report is the only code using log_print).

Looking at the opposite mixture - older libdm with newer lvm2 code,
that won't be compilable because the new log report functionality
that is in lvm2 also requires new dm_report_group_* libdm functions
so we don't need to care here.

log: move original print_log code to _vprint_log and make print_log a wrapper over _vprint_log

Move code from original print_log fn to a separate _vprint_log function
that accepts va_list and make print_log a wrapper over _vprint_log.
The print_log just initializes the va_list and uses it for _vprint_log
call now. This way, we can reuse _vprint_log if needed.

filters: add comments about internal filter position in filter chain

lvconvert: Fix --stripes handling.

Only treat --stripes as meaning --type striped if no other type was
first detected.  If a segtype got selected, don't override it later.

vgimportclone: add native command

This is cleaner and more efficient than the script.
The args and usage are unchanged.

lvconvert: Refactor argument handling code.

Begin disentangling the different lvconvert modes of operation
from each other.

tools: Use arg_is_set instead of arg_count.

vgcfgrestore: rescan to reenable lvmetad on error path

In commit 6ae22125, vgcfgrestore began disabling lvmetad
while running, and rescanned to enable it again at the end,
but missed the rescanning/enabling in the error case.

vgcfgrestore: check for missing device

The missing device will generally be seen earlier
and cause the command to not reach this point, but
check anyway for completeness.

lvmlockd: always try to connect to lvmetad

Reconnect to lvmetad if either the send fails (e.g. lvmetad
was restarted since lvmlockd last connected), or if no
lvmetad connection exists (e.g. lvmetad was started after
lvmlockd so no previous connection existed.)

lvmetad: process new connections after shutdown signal

Currently, a shutdown signal will cause lvmetad to quit
responding to new connections, but not actually exit until
all connections are gone.  If a program is maintaining a
long running connection (e.g. lvmlockd, or even an lvm
command) when lvmetad gets a shutdown signal, then all
further commands will hang indefinately waiting for a
response that won't be sent.

With this patch, make lvmetad continue handling new
connections even after a shutdown signal.  It will exit
once all connections are gone.

vgcfgrestore: use lvmetad disabled state

Previously, vgcfgrestore would attempt to vg_remove the
existing VG from lvmetad and then vg_update to add the
restored VG.  But, if there was a failure in the command
or with vg_update, the lvmetad cache would be left incorrect.
Now, disable lvmetad before the restore begins, and then
rescan to populate lvmetad from disk after restore has
written the new VG to disk.

vgscan: fix process_each args

zero/null args were mixed up.

conf: add more comments for new settings related to output format and log report

cleanup: log: use hex numbers instead of decimal for _LOG_*

log: add 'label' log report object type; annotate process_each_label with log_set_report_object_{type, id_and_name} and report_log_ret_code

report: compare --configreport value with basic report type

Reporting commands can be of different types (even if the command name
is the same):
  - pvs command can be either of PVS, PVSEGS or LABEL report type,
  - vgs command is of VGS report type,
  - lvs command is of LVS or SEGS report type.

Use basic report type when looking for report prefix used for
--configreport option.

This means that:
  - 'pvs --configreport pv' applies to PVS, PVSEGS or LABEL report type
  - 'vgs --configreport vg' applies to VGS report type
  - 'lvs --configreport lv' applies to LVS and SEGS report type

commands: add --configreport arg for all relevant commands

conf: regenerate profile templates

report: add --logonly arg to report only log for a command

report: use report type description for report's name if using DM_REPORT_GROUP_BASIC output format

libdm: select: recognize special selection string 'all' as an alias for blank selection string

conf: add log/command_log_selection config setting

log: use separate 'orphan' report object type for orphan VGs

tools: add 'lvm lastlog' command for interactive query and display of last command's log

If we're running in lvm shell, we can keep last command's log report
for further query with possible different selection criteria for easy
log lookup.

refactor: move 'interactive' field from struct command_line to struct cmd_context as 'is_interactive' switch

log: annotate processing code with report_current_object_cmdlog

log: annotate processing code with log_set_report_{context,object_type,id_and_name}

report: add 'multiple_output' arg to report_init

Some reports may be reported several times with possible different
selection criteria, just like command log report.

libdm: report: add dm_report_set_selection

Since we can do repeated dm_report_output calls now, we also like
to be able to set selection for each of these outputs.

libdm: report: add DM_REPORT_OUTPUT_MULTIPLE_TIMES report flag to keep report data even after output is done

The DM_REPORT_OUTPUT_MULTIPLE_TIMES instructs reporting code to
keep rows even after dm_report_output call - the rows are not
destroyed in this case which makes it possible to call dm_report_output
multiple times.

refactor: move field width calculation and sort preparation from _do_report_object to dm_report_output

This also prepares code for repeated dm_report_output calls.

libdm: report: remember special field to display selection status in struct row's field_sel_status variable

This allows for moving parts of the code from dm_report_object to
dm_report_output which is important for subsequent patches that allow
for repeated dm_report_output, not destroying rows on each
dm_report_output call.

log: also pass log_print through report and add log_print_bypass_report for use in libdm-report for direct print without report

log_print is used during cmd line processing to log the result of the
operation (e.g. "Volume group vg successfully changed" and similar).

We don't want output from log_print to be interleaved with current
reports from group where log is reported as well. Also, the information
printed by log_print belongs to the log report too, so it should be
rerouted to log report if it's set.

Since the code in libdm-report which is responsible for doing the report
output uses log_print too, we need to use a different kind of log_print
which bypasses any log report currently used for logging (...simply,
we can't call log_print to output the log report itself which in turn
would again reroute to report - the report would never get on output
this way).

report: add report_current_object_cmdlog fn as a shortcut for reporting current object's log item

log: log warnings and errors via report if set; add log_set_report* fns

This patch adds structures and functions to reroute error and warning
logs to log report, if it's set.

There are 5 new functions:
  - log_set_report
    Set log report where logging will be rerouted.

  - log_set_report_context
    Set context globally so any report_cmdlog call will use it.

  - log_set_report_object_type
    Set object type globally so any report_cmdlog call will use it.

  - log_set_report_object_name_and_id
    Set object ID and name globally so any report_cmdlog call will use it.

  - log_set_report_object_group_and_group_id
    Set object group ID and name globally so any report_cmdlog call will use it.

These functions will be called during LVM command processing so any logs
which are rerouted to log report contain proper information about current
processing state.

toollib: make it possible to also process internal VGs, add 'include_internal' switch to process_each_vg fn

The lvm fullreport works per VG and as such, the vg, lv, pv, seg and
pvseg subreport is done for each VG. However, if the PV is not part of
any VG yet, we still want to display pv and pvseg subreports for these
"orphan" PVs - so enable this for lvm fullreport's process_each_vg call.

report: check report type and options used for full report's subreports

If we have fullreport, make sure that the options/sort keys used for
each report doesn't change its type - we want to preserve the original
type so it's always 5 different subreports within fullreport (vg, lv, pv,
seg, pvseg). Since we have all report types within fullreport, users
should add fields under proper subreport type - this minimizes
duplication of info displayed on output.

report: recognize selection (-S|--select) for each subreport; make -S|--select groupable

report: recognize list of keys to sort report by (-O|--sort) for each subreport; make -O|--sort groupable

report: recognize list of fields to report (-o|--options) for each subreport

report: add _get_report_idx_from_name and _should_process_report_idx helper fns

Prepare for recognition of cmd line options for each subreport within
one command.

args: add --configreport arg

args: add priorities for grouping args

Groupable args (the ones marked with ARG_GROUPABLE flag) start a new
group of args if:
  - this is the first time we hit such a groupable arg,
  - or if non-countable arg is repeated.

However, there may be cases where we want to give priorities when
forming groups and hence force new group creation if we hit an arg
with higher grouping priority.

For example, let's assume (for now) hypothetical sequence of args used:

  lvs -o lv_name --configreport log -o log_type --configreport lv -o +vg_name

Without giving any priorites, we end up with:

  lvs -o lv_name --configreport log -o log_type --configreport lv -o +vg_name
     |                            | |                           | |          |
     \__________GROUP1___________/   \________GROUP2___________/   \_GROUP3_/

This is because we hit "-o" as the first groupable arg. The --configreport,
even though it's groupable too, it falls into the previous "-o" group.

While we may need to give priority to the --configreport arg that should
always start a new group in this scenario instead:

  lvs -o lv_name --configreport log -o log_type --configreport lv -o +vg_name
      |         | |                            | |                           |
      \_GROUP1_/   \_________GROUP2___________/   \_________GROUP3__________/

So here "-o" started a new group but since "--configreport" has higher
priority than "-o", it starts fresh new group now and hence the rest of
the command line's args are grouped by --configreport now.

conf: add report/{vgs,pvs,lvs,pvsegs,segs}_{cols,sort}_full config settings

commands: report: add lvm fullreport command

lvm fullreport executes 5 subreports (vg, pv, lv, pvseg, seg) per each VG
(and so taking one VG lock each time) within one command which makes it
easier to produce full report about LVM entities.

Since all 5 subreports for a VG are done under a VG lock, the output is
more consistent mainly in cases where LVM entities may be changed in
parallel.

commands: recognize --reportformat option for other commands

Enables --reportformat option for all command using processing_handle
(and process_each_* fn variant), that is: lvchange, lvcreate, lvdisplay,
lvextend, lvreduce, lvremove, lvrename, lvresize, lvscan, pvchange,
pvresize, pvcreate, pvdisplay, pvmove, pvremove, pvscan, vgcfgbackup,
vgchange, vgck, vgconvert, vgcreate, vgdisplay, vgexport, vgextend,
vgimport, vgmknodes, vgreduce, vgremove, vgrename command.

commands: recognize --reportformat option for pvs,vgs,lvs and devtypes command

Enables --reportformat options for pvs, vgs, lvs, devtypes command.

report: add current report to existing group

Add any report (pvs/vgs/lvs) currently processed to current report group
which is part of processing handle and which already contains log
report. This way both log report and pvs/vgs/lvs report will be
reported as a whole within a group, thus having same output format as
selected by --reportformat option.

toollib: add 'parent' field to processing_handle; init report format only if there's no parent

If there's parent processing handle, we don't need to create completely
new report group and status report - we'll just reuse the one already
initialized for the parent.

Currently, the situation where this matter is when doing internal report
to do the selection for processing commands where we have parent processing
handle for the command itself and processing handle for the selection
part (that is selection for non-reporting tools).

toollib: add report_group and log_rh to processing_handle and initialize cmd processing log report

Wire up report group creation with log report in struct
processing_handle and call report_format_init during processing handle
initialization (init_processing_handle fn) and destroy it while
destroing processing handle (destroy_processing_handle fn).

This way, all the LVM command processing using processing handle
has access to log report via which the current command log
can be reported as items are processed.

report: separate common report and per-report args

Separating common report and per-report arguments prepares the code for
handling several reports per one command (for example, the command log
report and LVM command report itself).

Each report can have sort keys, options (fields), list of fields to
compact and selection criteria set individually. Hooks for setting these
per report within one command will be a part of subsequent patches, this
patch only separates new struct single_report_args out of existing
struct report_args.

conf: add log/report_command_log config setting

conf: add report/output_format config setting

New report/output_format configuration sets the output format used
for all LVM commands globally. Currently, there are 2 formats
recognized:
   - basic (the classical basic output with columns and rows, used by default)
   - json (output is in json format)

toollib: add report_format_init fn to create report group and to create/add log report handle

Add new --reportformat option and new report_format_init function that
checks this option and creates new report group accordingly, also
preparing log report handle and adding it to the report group just
created.

conf: add log/command_log_{sort,cols} config settings

report: add CMDLOG report type

This is a preparation for new CMDLOG report type which is going to be
used for reporting LVM command log.

The new report type introduces several new fields (log_seq_num, log_type,
log_context, log_object_type, log_object_group, log_object_id, object_name,
log_message, log_errno, log_ret_code) as well as new configuration settings
to set this report type (report/command_log_sort and report/command_log_cols
lvm.conf settings).

This patch also introduces internal report_cmdlog helper function
which is a wrapper over dm_report_object to report command log via
CMDLOG report type and which is going to be used throughout the code
to report the log items.

libdm: report: implement DM_REPORT_GROUP_JSON for JSON report output

This patch introduces DM_REPORT_GROUP_JSON report group type. When using
this group type and when pushing a report to such a group, these flags
are automatically unset:

   DM_REPORT_OUTPUT_ALIGNED
   DM_REPORT_OUTPUT_HEADINGS
   DM_REPORT_OUTPUT_COLUMNS_AS_ROWS

...and this flag is set:

   DM_REPORT_OUTPUT_BUFFERED

The whole group is encapsulated in { } for the outermost JSON object
and then each report is reported on output as array of objects where
each object is the row from report:

  {
     "report_name1": [
         {field1="value", field2="value",...},
         {field1="value", field2="value",...}
         ...
     ],
     "report_name2": [
         {field1="value", field2="value",...},
         {field1="value", field2="value",...}
         ...
     ]
     ...
  }

libdm: report: implement DM_REPORT_GROUP_BASIC for extended report output

This patch introduces DM_REPORT_GROUP_BASIC report group type. This
type has exactly the classical output format as we know from before
introduction of report groups. However, in addition to that, it allows
to put several reports into a group - this is the very basic grouping
scheme that doesn't change the output format itself:

  Report: report1_name
  Header1  Header2 ...
  value    value   ...
  value    value   ...
  ...      ...     ...

  Report: report2_name
  Header1  Header2 ...
  value    value   ...
  value    value   ...
  ...      ...     ...

libdm: report: implement DM_REPORT_GROUP_SINGLE for a group containing single report only

There's no change in output for this report group type - with this type,
we only make sure there's always only one report in a group at a time,
not more.

libdm: report: introduce dm_report_group

This patch introduces DM report group (represented by dm_report_group
structure) that is used to group several reports to make a whole. As a
whole, all the reports in the group follow the same settings and/or
formatting used on output and it controls that the output is properly
ordered (e.g. the output from different reports is not interleaved
which would break readability and/or syntax of target output format
used for the whole group).

To support this feature, there are 4 new functions:
  - dm_report_group_create
  - dm_report_group_push
  - dm_report_group_pop
  - dm_report_group_destroy

From the naming used (dm_report_group_push/pop), it's clear the reports
are pushed onto a stack. The rule then is that only the report on top
of the stack can be reported (that means calling dm_report_output).
This way we make sure that the output is not interleaved and provides
determinism and control over the output.

Different formats may allow or disallow some of the existing report
flags controlling output itself (DM_REPORT_OUTPUT_*) to be set or not so
once the report is pushed to a group, the grouping code makes sure that
all the reports have compatible flags set and then these flags are
restored once each report is popped from the report group stack.

We also allow to push/pop non-report item in which case such an item
creates a structure (e.g. to put several reports together with any
opening and/or closing lines needed on output which pose as extra
formatting structure besides formatting the reports).

The dm_report_group_push function accepts an argument to pass any
format-specific data needed (e.g. handle, name, structures passed
along while working with reports...).

We can call dm_report_output directly anytime we need (with the only
restriction that we can call dm_report_output only for the report that
is currently on top of the group's stack). Or we don't need to call
dm_report_output explicitly in which case all the reports in a stack are
reported on output automatically once we call dm_report_group_destroy.

vgreduce: fix location of lvmlockd global lock

The lvmlockd global lock was missing the non-repair case,
which caused the new orphan PV created by vgreduce to
not be seen by other hosts.

lvmlockd: fix dropping PVs in rescanning VG

This fixes a problem in commit ae0a8740c.  The problem
in that commit was that all existing PVs are initially
dropped from lvmetad.  This works if the VG is updated
at the end, which replaces the dropped PVs, but if the
rescan finds that the VG seqno is unchanged, it leaves
the cached VG in place.  So, we should only drop the
existing PVs in lvmetad when the VG is going to be updated.

post-release

pre-release

tools: add missing destroy_processing_handle in pvscan and vgreduce code

pvscan: don't activate LVs when use_lvmetad=0

commit 15da467b was meant to address the case where
use_lvmetad=1 in lvm.conf, and lvmetad is not available,
in which case, pvscan --cache -aay should activate LVs.

But the commit unintentionally also changed the case
where use_lvmetad=0 in lvm.conf, in which case
pvscan --cache -aay should not activate LVs, so fix
that here.

pvscan: fix lvmlockd global lock

This should have been removed when pvscan was
recently converted to use process_each_pv which
does the lvmlockd locking.

pvscan: do activation when lvmetad is not running

When pvscan --cache -aay fails to connect to lvmetad it will
simply exit and do nothing.  Change this so that it will
skip the lvmetad cache step and do the activation step from
disk.

lvmlockd: fix rescanning VG

Previously, new PVs that were added to the VG were not scanned.

post-release

pre-release

lvmdbusd: Remove duplicate test code

lvmdbusd: Add test for DataLv & MetaDataLv

Added tests which expose an issue found with these properties.

lvmdbusd: Create correct LV object type

We were initially looking to see if an LV was hidden and if it was we were
creating an instance of a LvCommon object to represent it.  Thus if we
had a hidden cache pool for example we were missing the methods and
properties for the cache pool.  However, when we create the object path,
any hidden LVs, regardless of type/functionality will be placed in the
hidden path.

lvmdbusd: Add method get_object_path_by_lvm_id

The object manager method get_object_by_lvm_id was used in many cases for
the sole reason of getting the object path for the object.  Instead of
retrieving the object and then calling 'dbus_object_path' on the object, we
are adding a method which returns the object path.

lvmdbusd: Rename get_object_path_by_lvm_id

Renaming to get_object_path_by_uuid_lvm_id, to clarify that both the uuid
and the lvm id are required.

lvmdbusd: Change print statement to py3 syntax

lvmdbusd: Bug fix for missing LV properties

When we are processing the LVs we need to build up dbus objects from least
dependent to most dependent, so that we have information available when
constructing.

lvmdbusd: Add data_lv and metadata_lv to cache pool interface

See: https://bugzilla.redhat.com/show_bug.cgi?id=1342558

lvmdbusd: Add roles property to LV common interface

See: https://bugzilla.redhat.com/show_bug.cgi?id=1342559

WHATS_NEW: add recent changes

cleanup: typo in WHATS_NEW_DM

display: yes no prompt improvement

Original code missed to catch all apperances of SIGINT.
Also enhance logging when running in shell without tty.
Accept this regex as valid input:
'^[ ^t]*([Yy]([Ee]([Ss]|)|)|[Nn]([Oo]|))[ ^t]*$'

lvmdump: also collect output from lsblk command when running lvmdump -s

lsblk provides nice and quick overview of the storage/sysfs structure
that is useful for debugging - collect its output when running lvmdump -s.

vgcreate, pvcreate, vgextend: don't use a device with duplicates

If duplicate orphan PVs exist, don't allow one of them to be
used for vgcreate/pvcreate/vgextend.

lvmcache: fix duplicate handling with multiple scans

Some commands scan labels to populate lvmcache multiple
times, i.e. lvmcache_init, scan labels to fill lvmcache,
lvmcache_destroy, then later repeat

Each time labels are scanned, duplicates are detected,
and preferred devices are chosen.  Each time this is done
within a single command, we want to choose the same
preferred devices.  So, check for existing preferences
when choosing preferred devices.

This also fixes a problem with the list of unused duplicate
devs when run in an lvm shell.  The devs had been allocated
from cmd memory, resulting in invalid list entries between
commands.

lvmcache: add optional dev arg to lvmcache_info_from_pvid

A number of places are working on a specific dev when they
call lvmcache_info_from_pvid() to look up an info struct
based on a pvid.  In those cases, pass the dev being used
to lvmcache_info_from_pvid().  When a dev is specified,
lvmcache_info_from_pvid() will verify that the cached
info it's using matches the dev being processed before
returning the info.  Calling code will not mistakenly
get info for the wrong dev when duplicate devs exist.

This confusion was happening when scanning labels when
duplicate devs existed.  label_read for the first dev
would add an info struct to lvmcache for that dev/pvid.
label_read for the second dev would see the pvid in
lvmcache from first dev, and mistakenly conclude that
the label_read from the second dev can be skipped
because it's already been done.  By verifying that the
dev for the cached pvid matches the dev being read,
this mismatch is avoided and the label is actually read
from the second duplicate.

lvmetad: handle update failures

If a command gets stuck during an lvmetad update, lvmetad
will cancel that update after the timeout.  The next command
to check the lvmetad will see that lvmetad needs to be
populated because lvmetad will return token of "none" after
a timed out update (same as when lvmetad is not populated
at all after starting.)

If a command gets an error during an lvmetad update, it
will now just quit and leave its updating token in place.
That update will be cancelled after the timeout.

lvmetad: remove disabled case for "scan error"

Failures while populating lvmetad will be handling
differently in a subsequent commit.

lvmetad: define special update in progress string

blkdeactivate: fix regression in blkdeactivate causing dm and md devices to be skipped.

Commit #5b3a4a9 caused the "name" variable to be cleared if
declaration and assignment is on two lines so put it back
so it's on one line for it to work again.