new module: AIX Volume Group creating, resizing, removing

[kairoaraujo]

SUMMARY

It is a module to manage Volume Groups to AIX Logical Volume
Manager. With this module is able to create, resize and
remove a Volume Group.

ISSUE TYPE

• New Module Pull Request

COMPONENT NAME

aix_lvg

ANSIBLE VERSION

ansible 2.5.0 (aix_lvg bfeb840b21) last updated 2017/09/14 22:05:36 (GMT +200)
  config file = None
  configured module search path = ['/Users/kairoaraujo/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Users/kairoaraujo/Dev/aix_lvg/ansible/lib/ansible
  executable location = /Users/kairoaraujo/Dev/aix_lvg/ansible/bin/ansible
  python version = 3.6.2 (v3.6.2:5fd33b5926, Jul 16 2017, 20:11:06) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]

ADDITIONAL INFORMATION

None

[ansibot]

@AugustusKling @ColOfAbRiX @DavidWittman @EvanK @LinusU @abulimov @adejoux @agaffney @ahtik @Akasurde @azaghal @dankeder @david_obrien @davixx @dougluce @dsummersl @giovannisciortino @goozbach @groks @haad @hryamzik @jasperla @jhoekx @jsumners @jtyr @kevensen @lberruti @matze @maxamillion @mcv21 @molekuul @mpdehaan @mulby @natefoo @nibalizer @ovcharenko @pmarkham @pyykkis @risaacson @rosmo @saito-hideki @sfromm @srvg @tdtrask @tmshn @xen0l

As a maintainer of a module in the same namespace this new module has been submitted to, your vote counts for shipits. Please review this module and add shipit if you would like to see it merged.

click here for bot help

[molekuul]

Hi,
Nice to see someone is working on AIX, I thought I was the onlyone :-)

I have some remarks on the module:
Ansible modules are to set a status of a configuration, if you want to extend a volumegroup with a disk that's already in this volumegroup, the module should not fail, but should return changed: False, nothing changed.

When a disk is in use by a volumegroup, you exit the module with a fail,
but when the disk is in use as an ASM disk, you set the return to False, and let the create_extend_vg function handle this, why these different approaches?

If you give a list of disks, the module will fail if even one disk will fail the "usage check" is this wat you want?

Checkmode is a mode in Ansible where you check what will be changed when you run the module with these parameters, without actually doing the action. You didn't incorporate this in the module, however you state that you support checkmode.

There are limits of how many PP's a disk can contain. An AIX system calulates the PP size from the size of the disk if you do not specify this. why not let the system decide the value of the PP-size if not specified in the playbook?

When you are removing a pv from a volumegroup, you do not check if the pv is within this volumegroup, so the command will fail, but the result is correct, the disk is not part of the volumegroup, as you want, you should handle this situation better.

Take into account that a volumegroup must be varyon before taking actions on a volumegroup.

I hope you can do anything with my remarks.

Kind regards,

Joris Weijters

[kairoaraujo]

Hi @molekuul

Yes, as AIX is my main OS I am writing some modules, I have also almost ready to submit modules for filesystem and mksysb. Remarks are always welcome :)
Please, could you also check out my packaging/os/installp PR #30238 ?

I will go through your remarks and see I'll what I can do.

[kairoaraujo]

Working on @molekuul remarks.

[ansibot]

@kairoaraujo This PR contains @ mentions in at least one commit message. Those mentions can cause cascading notifications through GitHub and need to be removed. Please squash or amend your commits to remove the mentions.

click here for bot help

[kairoaraujo]

Hi @molekuul

I would like ask somethings regarding your remarks

Ansible modules are to set a status of a configuration, if you want to extend a volumegroup with a disk that's already in this volumegroup, the module should not fail, but should return changed: False, nothing changed.

I agree with that point and I'm implementing it.
My doubt is when the disk is already in use by another volume group, it should fail or also return not changed?

When a disk is in use by a volumegroup, you exit the module with a fail,
but when the disk is in use as an ASM disk, you set the return to False, and let the create_extend_vg function handle this, why these different approaches?
If you give a list of disks, the module will fail if even one disk will fail the "usage check" is this wat you want?

My approach is wrong, should be the same return for ASM and VG use. IMHO If you give a list of disks and one disk is wrong it should fail and forces the administrator correct the pool and avoid wrong resizes. Anyway, I'm opened to opinions.

Checkmode is a mode in Ansible where you check what will be changed when you run the module with these parameters, without actually doing the action. You didn't incorporate this in the module, however you state that you support checkmode.

I want to implement it, but I'm quite confused how to do it.

There are limits of how many PP's a disk can contain. An AIX system calulates the PP size from the size of the disk if you do not specify this. why not let the system decide the value of the PP-size if not specified in the playbook?

Totally agree, I'm changing it.

When you are removing a pv from a volumegroup, you do not check if the pv is within this volumegroup, so the command will fail, but the result is correct, the disk is not part of the volumegroup, as you want, you should handle this situation better.

It is treated by AIX as well, but for sure I do it also.

TASK [Reducing datavg with disk from rootvg] **************************************************************************************
fatal: [172.16.100.24]: FAILED! => {"changed": false, "err": "0516-1782 reducevg: Physical volume hdisk0 is not part of volume group datavg.\n0516-884 reducevg: Unable to remove physical volume hdisk0.\n", "failed": true, "msg": "Unable to remove datavg", "rc": 2}

We will have also this situation when the volume group still having filesystems mounted or open lv. I think is better leave it up to AIX, no?

Take into account that a volumegroup must be varyon before taking actions on a volumegroup.

Including this verification on the top.
About this subject, I will also include C(action): varyonv/varyoff it will be useful ;)

Kind regards,
Kairo Araujo

[jtyr]

The Check Mode should be implemented the way that if using ansible-play -C site.yaml, the module doesn't perform any real changes, it just reports whether it would perform any change if run without the Check Mode. In your case, you should just check if there already exists VG of that name or parameters and if not, you should not do any changes but just return a flag that a change would be done if running without a Check Mode. Code-wise it would look like this:

def state_vg(...):
    changed = False

    ...

    if state == 'varyon':
        if vg_state is False:
            changed = True

            if not module.check_mode:
                varyonvg_cmd = module.get_bin_path("varyonvg", True)
                rc, varyonvg_out, err = module.run_command(
                    "%s %s" % (varyonvg_cmd, vg))

                if rc != 0:
                    module.failed_json(msg="...", stdout=out, stderr=err)

    ...

    return changed


def main():
    if state == 'present':
        changed = create_extend_vg(...)
    elif state == 'absent':
        changed = reduce_vg(...)
    elif state == 'varyon' or 'varyoff':
         changed = state_vg(...)

    module.exit_json(changed=True, state=state)

[ansibot]

cc @MorrisA @dagwieers @flynn1973
click here for bot help

[ansibot]

cc @bcoca @wtcross
click here for bot help

[kairoaraujo]

I will write the integration test for this module as well before merge.

[ansibot]

cc @marvin-sinister @mator
click here for bot help

[ansibot]

cc @ramooncamacho
click here for bot help

[dagwieers]

rebuild_merge