community.general
community.general copied to clipboard
ansible-collections
lvol: specify activation option
SUMMARY
This issue was already submitted on the Ansible repo.
I think it would be useful to be able to specify the activation option (exclusive, shared, local) for LVs in a shared VG.
ISSUE TYPE
- Feature Idea
COMPONENT NAME
lvol
ADDITIONAL INFORMATION
We could introduce a new parameter activation_option which could take exclusive, shared or local as values.
- name: Activate a logical volume with shared lock
lvol:
vg: firefly
lv: test
active: true
activation_option: shared
Files identified in the description:
If these files are inaccurate, please update the component name section of the description or use the !component bot command.
cc @MorrisA @abulimov @bcoca @d-little @flynn1973 @gforster @jhoekx @kairoaraujo @marvin-sinister @mator @molekuul @ramooncamacho @wtcross click here for bot help
I think it would be more convenient to just be able to pass any options to lvchange: what about lvchange_opts?
Alternatively: allow 'active' option to be boolean (for compatibility) or any string appended to -a option to lvchange, like:
- name: Activate a logical volume with shared lock
lvol:
vg: firefly
lv: test
active: sy
Passing this to lvchange_opts, for instance lvchange_opts: -asy would interfere with the existing active parameter. Indeed, the type of activation isn't an option to add to the command line. If you need a shared activation, you need to replace -a (shortcut for -ae) by -as.
I think the second solution is ok.
Adding a generic option like lvchange_opts is usually not a good idea. I would avoid it if possible.
Then adding generic values like 'sy' to 'activate' is not a very good idea
either... Better we'd have boolean (yes/no/true/false etc.) and special
(exclusive, shared, local) values for active field.
Are multitype values (boolean or string) allowed/supported somehow or we need to change type to string and parse boolean values inside module?
I find ugly to have an "almost boolean" parameter, which can take a boolean but also a string as a value. That's why I prefer an extra parameter.
But I admit that activation_option name is kind of ugly too...
We could name it lock instead.
Files identified in the description:
If these files are incorrect, please update the component name section of the description or use the !component bot command.