Peter Rajnoha [Wed, 11 Feb 2015 08:21:08 +0000 (09:21 +0100)]
man: dumpconfig: mention LVM_COMMAND_PROFILE env var and add more references to --mergedconfig option
The LVM_COMMAND_PROFILE env var is new - mention it in dumpconfig's
man page.
Also, dumpconfig always displays the top of the config cascade.
To display all the config found in the cascade merged (just like
it's used during LVM command processing), --mergedconfig option
must be used - this one's already described in that man page,
just make sure it's clear and add reference for this option also
in --profile/--commandprofile/--metadataprofile description.
Peter Rajnoha [Tue, 10 Feb 2015 12:46:37 +0000 (13:46 +0100)]
select: initialize selection handle for process_each_* fns with initial report type
This is a followup patch for previous patchset that enables selection in
process_each_* fns to fix an issue where field prefixes are not
automatically used for fields in selection criteria.
Use initial report type that matches the intention of each process_each_* functions:
- _process_pvs_in_vg - PVS
- process_each_vg - VGS
- process_each_lv and process_each_lv_in_vg - LVS
This is not normally needed for the selection handle init, BUT we would
miss the field prefix matching, e.g.
lvchange -ay -S 'name=lvol0'
The "name" above would not work if we didn't initialize reporting with
the LVS type at its start. If we pass proper init type, reporting code
can deduce the prefix automatically ("lv_name" in this case).
This report type is then changed further based on what selection criteria we
have. When doing pure selection, not report output, the final report type
is purely based on combination of this initial report type and report types
of the fields used in selection criteria.
Peter Rajnoha [Fri, 12 Dec 2014 09:20:15 +0000 (10:20 +0100)]
tools: allow -S|--select for vgdisplay, lvdisplay and pvdisplay without -C
We already allowed -S|--select with {vg,lv,pv}display -C (which
was then equal to {vg,lv,pv}s command. Since we support selection
in toolib now, we can support -S also without using -C in *display
commands now.
Peter Rajnoha [Wed, 3 Dec 2014 09:02:13 +0000 (10:02 +0100)]
pvchange: use processing_handle when processing items for pvchange
pvchange is an exception that does not use toollib yet for iterating
over the list of PVs (process_each_pv) so intialize the
processing_handle and use just like it's used in toollib.
Peter Rajnoha [Mon, 1 Dec 2014 14:40:03 +0000 (15:40 +0100)]
report: implement report_for_selection
We have 3 input report types:
- LVS (representing "_select_match_lv")
- VGS (representing "_select_match_vg")
- PVS (representing "_select_match_pv")
The input report type is saved in struct selection_handle's "orig_report_type"
variable.
However, users can use any combination of fields of different report types in
selection criteria - the resulting report type can thus differ. The struct
selection_handle's "report_type" variable stores this resulting report type.
The resulting report_type can end up as one of:
- LVS
- VGS
- PVS
- SEGS
- PVSEGS
This patch adds logic to report_for_selection based on (sensible) combination
of orig_report_type and report_type and calls appropriate reporting functions
or iterates over multiple items that need reporting to determine the selection
result.
Peter Rajnoha [Mon, 1 Dec 2014 13:19:30 +0000 (14:19 +0100)]
report: add report_for_selection and use it in select_match_{pv,vg,lv}
The report_for_selection does the actual "reporting for selection only".
The selection status will be saved in struct selection_handle's "selected"
variable.
Peter Rajnoha [Mon, 1 Dec 2014 13:04:29 +0000 (14:04 +0100)]
refactor: report: factor out code to determine final report type
The code to determine final report type based on combination of input
report type (determined from fields used for reporting to output and selection)
can be reused for pure reporting for selection - factor out this code into
_get_final_report_type function.
Peter Rajnoha [Wed, 3 Dec 2014 13:20:00 +0000 (14:20 +0100)]
toollib: select the whole structure if at least one of its items is selected
This applies to:
- process_each_lv_in_vg - the VG is selected only if at least one of its LVs is selected
- process_each_segment_in_lv - the LV is selected only if at least one of its LV segments is selected
- process_each_pv_in_vg - the VG is selected only if at least one of its PVs is selected
- process_each_segment_in_pv - the PV is selected only if at least one of its PV segments is selected
So this patch causes the selection result to be properly propagated up to callers.
Peter Rajnoha [Fri, 28 Nov 2014 14:04:25 +0000 (15:04 +0100)]
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns
Call _init_processing_handle, _init_selection_handle and
_destroy_processing_handle in process_each_* and related functions to
set up and destroy handles used while processing items.
Peter Rajnoha [Fri, 28 Nov 2014 13:46:18 +0000 (14:46 +0100)]
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions
The init_processing_handle, init_selection_handle and
destroy_processing_handle are helper functions that allocate and
initialize the handles used when processing items in process_each_*
and related functions.
Peter Rajnoha [Fri, 28 Nov 2014 13:34:56 +0000 (14:34 +0100)]
toollib: pass struct processing_handle to _select_match_* functions
The "struct processing_handle" contains handles to drive the selection/matching
so pass it to the _select_match_* functions which are entry points to the
selection mechanism used in process_each_* and related functions.
This is revised and edited version of former Dave Teigland's patch which
provided starting point for all the select support in process_each_* fns.
Peter Rajnoha [Tue, 2 Dec 2014 12:14:12 +0000 (13:14 +0100)]
report: add report_init_for_selection fn and modify report_object to support reporting for selection only
The new "report_init_for_selection" is just a wrapper over
dm_report_init_with_selection that initializes reporting for selection
only. This means we're not going to do the actual reporting to output
for display and as such we intialize reporting as if no fields are reported
or sorted. The only fields "reported" are taken from the selection criteria
string and all such fields are marked as hidden automatically (FLD_HIDDEN flag).
These fields are used solely for selection criteria matching.
Also, modify existing report_object function that was used for reporting to
output for display. Now, it can either cause reporting to output or reporting
for selection only. The selection result is stored in struct selection_handle's
"selected" variable which can be handled further by any report_object caller.
Peter Rajnoha [Thu, 27 Nov 2014 14:02:13 +0000 (15:02 +0100)]
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related)
This patch replaces "void *handle" with "struct processing_handle *handle"
in process_each_*, process_single_* and related functions.
The struct processing_handle consists of two handles inside now:
- the "struct selection_handle *selection_handle" used for
applying selection criteria while processing process_each_*,
process_single_* and related functions (patches using this
logic will follow)
- the "void* custom_handle" (this is actually the original handle
used before this patch - a pointer to custom data passed into
process_each_*, process_single_* and related functions).
Peter Rajnoha [Mon, 24 Nov 2014 10:07:39 +0000 (11:07 +0100)]
libdm: report: add dm_report_object_is_selected
The new dm_report_object_is_selected fn makes it possible to opt whether the
object reported should be displayed on output or not. Also, in addition to
that, it makes it possible to save the result of selection (either 0 or 1).
So dm_report_object_is_selected is simply more general form of object
reporting fn - combinations now allow for:
dm_report_object_is_selected(rh, object, 1, NULL):
This is exactly the original dm_report_object fn and it's fully equal
to it.
dm_report_object_is_selected(rh, object, 0, selected):
Do not display the result on output, but save info whether the object
is selected or not in 'selected' variable.
dm_report_object_is_selected(rh, object, 1, selected):
Display the result on output (if it passes selection criteria) and save
whether the object is selected or not in 'selected' variable.
dm_report_object(rh, object, 0, NULL):
This combination is not allowed - it will end up with internal error.
We're either interested in selection status or we want to display the
result on output or both, but never nothing of the two.
Peter Rajnoha [Mon, 9 Feb 2015 13:16:24 +0000 (14:16 +0100)]
lvm: recognize LVM_COMMAND_PROFILE env var for default command profile to use in LVM commands
Once LVM_COMMAND_PROFILE environment variable is specified, the profile
referenced is used just like it was specified using "<lvm command> --commandprofile".
If both --commandprofile cmd line option and LVM_COMMAND_PROFILE env
var is used, the --commandprofile cmd line option gets preference.
Petr Rockai [Thu, 26 Jun 2014 23:25:18 +0000 (01:25 +0200)]
NIX: Refactor around the new test runner.
- The RPM build and the tests are now executed in separate VMs.
- Run the testsuite by using the new lvm2-testsuite RPM.
- The VM running the tests is restarted from the outside if it hangs, and the
runner keeps a journal to avoid running a bad test ad infinitum.
- TODO: lcov reports and more intelligent VM rebooting (track the journal)