Add yes argument when creating/extending a LV

[bmlit]

issue

(related to #278)
This module is failing when trying to create a XFS LV on location where a XFS LV was present :

Execution of '/sbin/lvcreate -n foo --size 160G main_vg' returned 5: WARNING: xfs signature detected on /dev/main_vg/foo at offset 0. Wipe it? [y/n]: [n]
Aborted wiping of xfs.
1 existing signature left on the device.
Failed to wipe signatures on logical volume main_vg/foo.
Aborting. Failed to wipe start of new LV.

solution

A fix is to add the --yes option which can be used for automatically answer the above interactive question.

implementation choices

This argument apply on the lvcreate/lvextend command as they're taking new blocks for the the LV, and therefore may trigger the issue.

I set it by default to true for being more versatile and avoiding Puppet run failure.
The man page discourage it (Use with extreme caution. (For automatic no, see -qq.)) but Puppet is here for automating thinks and the user should know the consequences.

[CLAassistant]

All committers have signed the CLA.

[puppet-community-rangefinder]

logical_volume is a type

Breaking changes to this file MAY impact these 5 modules (near match):

• dharknes-scst
• maxadamo-galera_maxscale
• maxadamo-tiny_nas
• puppetlabs-lvm
• maxadamo-galera_proxysql

lvm::logical_volume is a type

Breaking changes to this file WILL impact these 1 modules (exact match):

• glorpen-g_server

Breaking changes to this file MAY impact these 1 modules (near match):

• example42-psick

This module is declared in 11 of 579 indexed public Puppetfiles.

---

These results were generated with Rangefinder, a tool that helps predict the downstream impact of breaking changes to elements used in Puppet modules. You can run this on the command line to get a full report.

Exact matches are those that we can positively identify via namespace and the declaring modules' metadata. Non-namespaced items, such as Puppet 3.x functions, will always be reported as near matches only.

[SHWETHABHAT1]

If we set it to false by default, then is there no option to wipe signatures, or for sending --yes to the prompt ?

[bmlit]

This is the purpose of this PR to add the --yes option.

It will be set by default to false, so you'll have to set it explicitly.
For example :

logical_volume { 'mylv':
  ensure       => present,
  volume_group => 'myvg',
  size         => '20G',
  yes          => true,
}

[bmlit]

@bastelfreak is everything ok for the creation of a new minor release ?

[jordanbreen28]

@bmlit thanks for this!
This module has recently become officially supported by the CAT Team at Puppet, so we are looking to get this moving forward!
Are you able to resolve the conflicts?

I wonder if we can give a more meaningful name to the parameter as well, maybe something as simple as $yes_flag? Just a thought, open to suggestions…

[jordanbreen28]

Hey @bmlit - did you get the chance to review the conflicts?

[bmlit]

Hi @jordanbreen28 ,
You're right the naming $yes_flag is more explicit than a simple $yes which can be misinterpreted.

The conflict was quite simple to fix while keeping the same logic, but I can't test it though..

[jordanbreen28]

Nice @bmlit thanks for that!
Yeah I suspect this is due to recent access change to repo level variables for forked PRs.
Let me see if I can dig into it abit more and get this moving.

[jordanbreen28]

@bmlit can you rebase off of main?
The issue with the tests has been resolved, so this should be good to go once green.

[jordanbreen28]

@bmlit couple of puppet-lint errors, could you look to resolve?
Can be resolved by adding class-level documentation for the new parameters, and removing the Optional datatype from the $yes_flag parameter as this value will never be undef.

[bmlit]

@jordanbreen28 I rebased it from main and fixed the tests.
Either correcting the coding style directly, either increasing the thresholds from .rubocop_todo.yml.

These thresholds are mainly coming from 41fc476 but I didn't have access to CONT-745 for checking why they was put so close to the current values.

[jordanbreen28]

LGTM.
Great work on this one @bmlit!

[tr0k]

@jordanbreen28 when do you expect the next release (tag) for this contribution to be reflected?

[jordanbreen28]

@tr0k we are just waiting on a couple of decisions to be made on other open PRs and bug fixes to go in before we release.
A release will be cut within the next couple of weeks. :-)

[tr0k]

Thanks for the quick reply! W8 impatiently for any updates on this. Cheers!