dell / ansible-powermax Goto Github PK

Describe the bug
The redirect entries in meta/runtime.yml do not contain FQCNs, but short names: https://github.com/dell/ansible-powermax/blob/1.8.0/meta/runtime.yml#L6-L81

This will result in an error with ansible-core 2.14, see ansible/ansible#78755.

Describe the solution you'd like
Currently info.py module doesn't return volume_identifier of volumes as part of return dictionary, but is able to filter on it.
volume_identifier is only seen on volume_details in volume.py module, but that require to querying multiple volumes in loop.

Describe alternatives you've considered
Query multiple volumes in loop using volume.py, but that approach is slow.

Additional context
We manage volumes/devices using volume_identifier, so having it returned from info.py (like volume name in different storage array modules) could be helpfull.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

• name: Create Child initiato groups
  dellemc.powermax.host:
  unispherehost: "{{unispherehost}}"
  universion: "{{universion}}"
  verifycert: "{{verifycert}}"
  user: "{{user}}"
  password: "{{password}}"
  serial_no: "{{serial_no}}"
  host_name: "{{'IG_'+item.name | upper }}"
  host_flags:
  consistent_lun: true
  state: 'present'
  initiators: "{{ item.initiators}}"
  initiator_state: 'present-in-host'
  register: childIgCreateResponse
  loop: "{{ hosts }}"
  ...
  hosts:
  • name: "REGTESTESX041"
    initiators:
    • "3311111111111EA2"
    • "3311111111111EA3"
  • name: "REGTESTESX042"
    initiators:
    • "3311111111111EA4"
    • "3311111111111EA5"

n. Step n See error

failed: [localhost] (item={'name': 'REGTESTESX041', 'initiators': ['3311111111111EA2', '3311111111111EA3']}) => {"ansible_loop_var": "item", "changed": false, "item": {"initiators": ["3311111111111EA2", "3311111111111EA3"], "name": "REGTESTESX041"}, "msg": "Adding initiators ['3311111111111EA2', '3311111111111EA3'] to host IG_REGTESTESX041 failed with error Bad or unexpected response from the storage volume backend API: Error PUT symmetrix resource. The status code received is 500 and the message is {'message': 'A problem occurred modifying the host resource: Error for: 000297900442/IG_REGTESTESX041: The operation can not be performed because the group is already in this state'}."}
failed: [localhost] (item={'name': 'REGTESTESX042', 'initiators': ['3311111111111EA4', '3311111111111EA5']}) => {"ansible_loop_var": "item", "changed": false, "item": {"initiators": ["3311111111111EA4", "3311111111111EA5"], "name": "REGTESTESX042"}, "msg": "Adding initiators ['3311111111111EA5', '3311111111111EA4'] to host IG_REGTESTESX042 failed with error Bad or unexpected response from the storage volume backend API: Error PUT symmetrix resource. The status code received is 500 and the message is {'message': 'A problem occurred modifying the host resource: Error for: 000297900442/IG_REGTESTESX042: The operation can not be performed because the group is already in this state'}."}

Expected behavior
Module should not care about case, WWN should be normalised on API side to match for idempotency regardless of upper|lower this is the behaviour in PowerMax CLI

Screenshots
If applicable, add screenshots to help explain your problem.

Logs
If applicable, submit logs or stack traces from the affected services

System Information (please complete the following information):

• OS/Version: RHEL 8.2
• PowerMax Collection 1.8

Additional context
Add any other context about the problem here.

Describe the bug
A clear and concise description of what the bug is.

storagegroup.py calls get_storage_group_snapshot_generation_list with the wrong parameter.

https://github.com/dell/ansible-powermax/blob/189e5ad993e5351d5c9dcdfcbb7ca40c6a993feb/plugins/modules/storagegroup.py#L1437C25-L1437C40

        for snap in snap_list:
            gen_list = self.replication.\
                get_storage_group_snapshot_generation_list(
                    storagegroup_id=sg_name,
                    snap_name=snap)

Should be
for snap in snap_list:
gen_list = self.replication.
get_storage_group_snapshot_generation_list(
storage_group_id=sg_name,
snap_name=snap)

fatal: [localhost]: FAILED! => {"changed": false, "msg": "Delete storage group X999RSWP_12312423_tmp99CRTEST_RSWP failed with error get_storage_group_snapshot_generation_list() got an unexpected keyword argument 'storagegroup_id' "}

Please fix, issue seen at HSBC

Describe the solution you'd like
When moving devices that are SRDF protected the Ansible, moving of devices is blocked. API will allow me to do this. Customer HSBC have reverted to URI module to accomplish this

Describe alternatives you've considered
URI Module

Additional context
Customer needs to be able to force move devices in and out of SRDF storage groups keeping SRDF protection on the devices even if it will render them unmanageable, they maintain separate SG for SRDF and Provisioning so this is a common occurrence for them and a blocker for ansible

Describe the solution you'd like
Need to be able to obtain HLU information for masking views needed for workflow automation

Describe alternatives you've considered
using URI module to workaround.

Additional context
Supported in PyU4V provisioning.get_masking_view_connections

Describe the solution you'd like
Add support for getting the volume pairs information for the SRDF group for a specific volume. The current ansible module retrieves all the devices in the RDF group and then we need to filter the information for a particular volume ID.

- name: Get the details of rdf group and volumes
  dellemc.powermax.rdfgroup:
    unispherehost: "{{unispherehost}}"
    universion: "{{universion}}"
    verifycert: "{{verifycert}}"
    user: "{{user}}"
    password: "{{password}}"
    serial_no: "{{serial_no}}"
    rdfgroup_number: "{{rdfgroup_id}}"

Describe alternatives you've considered
Using the ansible.builtin.uri module to retrieve this information

- name: Collect Device pair information through API
      uri:
        url: "https://{{unispherehost}}:8443/univmax/restapi/92/replication/symmetrix/{{serial_no}}/rdf_group/{{rdfg}}/volume/{{item}}"
        method: GET

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
When attempting to install this collection into an execution environment via the ansible-builder command, the build fails with an error that the requirements.txt file is not found. This appears to be caused by the use of a relative path in the meta/execution-environment.yml file.

To Reproduce
Steps to reproduce the behavior:

1. Step 1 install the collection with ansible-galaxy collection install dellemc.powermax
2. Step 2 test collection with ansible-builder introspect --sanitize ~/.ansible/collections/
3. Step 3 see error
   Expected requirements file not present at: /home/user/.ansible/collections/ansible_collections/dellemc/requirements.txt
   FileNotFoundError: [Errno 2] No such file or directory: '/home/user/.ansible/collections/ansible_collections/dellemc/powermax/../requirements.txt'
   Note the parent folder reference ../requirements.txt
4. Step 4 edit meta/execution-environment.yml and remove the relative path

---
version: 1
dependencies:
  galaxy: requirements.yml
  python: requirements.txt

6. Step 5 test collection again and see proper output

Expected behavior
ansible-builder introspect command should list correct dependencies

---
python:
- 'urllib3>=1.26.7  # from collection dellemc.powermax'
- 'PyU4V>=9.1.2.0  # from collection dellemc.powermax'
- 'setuptools  # from collection dellemc.powermax'

System Information (please complete the following information):
ansible --version
ansible [core 2.12.1]
config file = /etc/ansible/ansible.cfg
configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.8/site-packages/ansible
ansible collection location = /home/user/.ansible/collections:/usr/share/ansible/collections
executable location = /usr/bin/ansible
python version = 3.8.8 (default, Aug 25 2021, 16:13:02) [GCC 8.5.0 20210514 (Red Hat 8.5.0-3)]
jinja version = 2.10.3
libyaml = True

We are currently deploying our PowerMax setup via Ansible and we notice that when creating a new host, the code doesn't appear to be idempotent.

See attached image;

The following code is being used to deploy that ( a bit sanitized);

- name: "Create PowerMax host for {{ host }}"
dellemc.powermax.dellemc_powermax_host:
unispherehost: "{{ host }}"
universion: "{{ version }}"
verifycert: "{{ verifycert }}"
serial_no: "{{ serial }}"
user: "{{ username }}"
password: "{{ password }}"
host_name: "{{ host_name"
host_type: "default"
state: "present"
initiator_state: "present-in-host"
initiators: "{{ initiators }}"

Currently when using the storagegroup module to create new volumes to an existing storage group, vol_name needs to be provided to label the volume. Is there any way of not making vol_name a required input? There's no requirement in the storage array to label a volume when creating volumes for a SG. Currently I add a randomly generated string to vol_name to be able to use this module to create volumes to a SG over and over again without any vol_names conflicting.

Or is there any other way of achieving the very same thing without having to add a random string to vol_name?

• name: Create new volumes for existing SG
  dellemc.powermax.storagegroup:
  unispherehost: "{{unispherehost}}"
  universion: "{{universion}}"
  verifycert: "{{verifycert}}"
  user: "{{user}}"
  password: "{{password}}"
  serial_no: "{{serial_no}}"
  sg_name: "foo"
  state: "present"
  volumes:
  • vol_name: "bar"
    size: 1
    cap_unit: "GB"
    vol_state: "present-in-group"

When not using a unique vol_name it does return:

"msg": "A volume with identifier bar but different size 6.0 GB already exists. Use a different identifier for volume creation. Currently, we support only unique identifiers for volume creation on PowerMax from Ansible"

Describe the bug
Info Module is looping on all masking views to filter for lun addresses

To Reproduce
Steps to reproduce the behavior:
- name: Get list of masking view connections with filter
dellemc.powermax.info:
unispherehost: "{{localDetail.mgmt_server}}"
universion: "{{universion}}"
verifycert: "{{verifycert}}"
user: "{{credential.username}}"
password: "{{credential.password}}"
serial_no: "{{localDetail.array}}"
gather_subset:
- mv_connections
filters:
- filter_key: "volume_id"
filter_operator: "equal"
filter_value: "{{item.volumeId}}"
loop: "{{ volDetail }}"
register: mvConnResponse

...
n. Step n See error
Code is
def get_mv_connections_list(self, filters_dict=None):
"""Get the list of masking view connections of a given PowerMax or VMAX storage
system"""

    try:
        LOG.info('Getting Masking View Connections List')
        array_serial_no = self.module.params['serial_no']
        masking_view_list = self.get_masking_view_list()
        mv_connections_list = []
        for masking_view_id in masking_view_list:
            connections = self.provisioning.get_masking_view_connections(masking_view_id, filters=filters_dict)
            if connections:
                mv_connections_list.append(
                    {
                        'masking_view_id': masking_view_id,
                        'masking_view_connections': connections
                    }
                )
        LOG.info('Got %d Getting Masking Views Connections from array %s',
                 len(mv_connections_list), array_serial_no)
        return mv_connections_list

Expected behavior
Customer should be able to filter on masking view, to correct a new optional paramter for masking view name should be allowed which would avoid the loop

System Information (please complete the following information):

• Ansible Collection - Latest

Additional context
Masking view connections REST API is intensive on API server so running this the way it is is potentially going to slow down unisphere server for customer with large number of masking views.

Describe the bug
Support is tied to closely to exact release of PyU4V

To Reproduce
Steps to reproduce the behavior:

1. Install PyU4V latest and you will get this error when trying to run any script

Expected behavior
In family upgrade of PyU4V should not be a problem

Describe the solution you'd like
Allow the possibility to set a different port then the default 8443 hardcoded one.

Describe alternatives you've considered
A port-forwarding iptables rule