search

ansible-collections / community.general

Ansible Community General Collection
https://galaxy.ansible.com/ui/repo/published/community/general/
GNU General Public License v3.0
821 stars 1.51k forks source link

lvol: specify activation option #538

Open raspbeguy opened 4 years ago

raspbeguy commented 4 years ago
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
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
ansibullbot commented 4 years ago

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.

click here for bot help

ansibullbot commented 4 years ago

cc @MorrisA @abulimov @bcoca @d-little @flynn1973 @gforster @jhoekx @kairoaraujo @marvin-sinister @mator @molekuul @ramooncamacho @wtcross click here for bot help

rosowiecki commented 4 years ago

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
raspbeguy commented 4 years ago

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.

felixfontein commented 4 years ago

Adding a generic option like lvchange_opts is usually not a good idea. I would avoid it if possible.

rosowiecki commented 4 years ago

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?

raspbeguy commented 4 years ago

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.

raspbeguy commented 4 years ago

But I admit that activation_option name is kind of ugly too...

We could name it lock instead.

ansibullbot commented 3 years ago

cc @unkaputtbar112 @zigaSRC click here for bot help

ansibullbot commented 1 year ago

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.

click here for bot help