Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map LUNs to initiator ACLs individually #5

Open
eggzotic opened this issue Sep 6, 2021 · 10 comments
Open

Map LUNs to initiator ACLs individually #5

eggzotic opened this issue Sep 6, 2021 · 10 comments
Assignees

Comments

@eggzotic
Copy link

eggzotic commented Sep 6, 2021

Hi Ondrej, thanks for creating these great modules for targetcli. For our situation, we have 4 distinct target entries under /iscsi and under each /iscisi/target_iqn/tpg1/acls/initiator_iqn I would like to create a LUN mapping. However, among these modules I cannot see the specific one that effectively executes the "create mapped_lun=... tpg_lun_or_backstore=..." command. The example at the play/role level (step3 of https://www.famera.cz/blog/ansible/ansible_targetcli.html) looks like it would work if I had only a single target WWN/iQN only - but we have 4 in this case (one for each Infiniband HCA), and I don't think we can loop at the play-level (only at the task-level)? I have separately extracted the 4x taget WWNs into a list variable and would like to loop over them applying the same "create mapped_lun=... tpg_lun_or_backstore=..." commands under each respective acls folder?

@OndrejHome
Copy link
Owner

Hi Richard,
Thank you for using the modules and for the question here.

Let me try to rephrase if I understand your question correctly:
Lets assume a bit simpler case where we have 3 LUNs and 1 iscsi target. These 3 LUNs will be exported by this target, but to different clients (ACL IQNs) only some of the LUNs will be visible, right?
For visualization it may look like this:

o- iqn.2003-01.org.linux-iscsi.xxx:yyy ................. [TPGs: 1]
  o- tpg1 ................................. [no-gen-acls, no-auth]
    o- acls ............................................ [ACLs: 1]
    | o- iqn.2003-01.org.linux-iscsi.client1:111  [Mapped LUNs: 2]
    |   o- mapped_lun0 ................... [lun0 block/test1 (rw)]
    |   o- mapped_lun1 ................... [lun1 block/test3 (rw)]
    | o- iqn.2003-01.org.linux-iscsi.client2:222  [Mapped LUNs: 1]
    |   o- mapped_lun0 ................... [lun0 block/test2 (rw)]
    o- luns ............................................ [LUNs: 3]
    | o- lun0 ................... [block/test1 (/dev/c7vg/test1) ]
    | o- lun1 ................... [block/test2 (/dev/c7vg/test2) ]
    | o- lun2 ................... [block/test3 (/dev/c7vg/test3) ]
    o- portals ...................................... [Portals: 1]
      o- 0.0.0.0:3260 ....................................... [OK]

In above there is client1:111 that see 2 LUNs and client2:222 that sees one LUN. If you could let me know if the above is the use case you are looking for, I can have a look at the code over weekend and let you know if there is a simple way to implement this into the modules. If my understanding is not correct, could you please give me some example from 'targetcli' when you configure the desired configuration manually so I have better idea what you are looking for?

As for the "looping" part of your question, the ondrejhome.targetcli role is looping over multiple target WWNs wher it add all the ACLs with default LUN mapping (= all LUNs) so if there was functionality that would allowed to tell which ACL in which target WWN should have access to which LUNs it should be possible to be made into task to loop over - note this is my quick glance at how it looks and I would have to "look better" at it give accurate answer. In any case I will try to leave you some more feedback over upcoming weekend unless there is some other emergency on my side. Thank you for understanding.

@OndrejHome OndrejHome self-assigned this Sep 8, 2021
@eggzotic
Copy link
Author

eggzotic commented Sep 8, 2021

Hi Ondrej, here is a look at the LIO config. So I have some tasks that:

  1. queries to find those 4 target iQNs below.
  2. use your target_iscsi_acl and targetcli_iscsi_lun modules, in tasks with a loop, to populate entries under the .../tpg1/acls and .../tpg1/luns dirs of each target.
  3. Finally, I'd like to have a task, that could loop over the targets 1 more time, to perform the create mapped_lun=... tpg_lun_or_backstore=... under each. Am I missing how simple this should be (I'm often good at that, lol!)?
$ sudo targetcli ls /iscsi 3
o- iscsi .............................................................................................................. [Targets: 4]
  o- iqn.2021-07.io.nyriad-iscsi:ref7-porta ...................................................................... [TPGs: 1]
  | o- tpg1 ................................................................................................. [no-gen-acls, no-auth]
  |   o- acls ............................................................................................................ [ACLs: 6]
  |   o- luns ........................................................................................................... [LUNs: 15]
  |   o- portals ...................................................................................................... [Portals: 1]
  o- iqn.2021-07.io.nyriad-iscsi:ref7-portb ...................................................................... [TPGs: 1]
  | o- tpg1 ................................................................................................. [no-gen-acls, no-auth]
  |   o- acls ............................................................................................................ [ACLs: 6]
  |   o- luns ........................................................................................................... [LUNs: 15]
  |   o- portals ...................................................................................................... [Portals: 1]
  o- iqn.2021-07.io.nyriad-iscsi:ref7-portc ...................................................................... [TPGs: 1]
  | o- tpg1 ................................................................................................. [no-gen-acls, no-auth]
  |   o- acls ............................................................................................................ [ACLs: 6]
  |   o- luns ........................................................................................................... [LUNs: 14]
  |   o- portals ...................................................................................................... [Portals: 1]
  o- iqn.2021-07.io.nyriad-iscsi:ref7-portd ...................................................................... [TPGs: 1]
    o- tpg1 ................................................................................................. [no-gen-acls, no-auth]
      o- acls ............................................................................................................ [ACLs: 6]
      o- luns ........................................................................................................... [LUNs: 14]
      o- portals ...................................................................................................... [Portals: 1]

@OndrejHome
Copy link
Owner

Hi Richard,

Thank you for answer. I think I have now good understanding on what you would like to do.
The short answer for "how can it be done with role now?" is that cannot :)

  • At present the initiators option needs to be populated (which is not required by targetcli, but made by role and I'm thinking about changing it)
  • later on the targetclie_iscsi_acl can only create/delete the "ACL directory" and while doing so it is basically using the add_mapped_luns=true as default which adds all luns from target to any given ACL so there is no granularity

The longer answer is: I think it will be possible to add the functionality and make it work, but it will take me some time to prepare the code. My expectation on how it could look like after improving the code is as follows:

  vars:
    iscsi_targets:
      - wwn: "iqn.1994-05.com.redhat:porta"
        disks:
          - path: /dev/c7vg/LV1
            name: test1
            type: block
          - path: /dev/c7vg/LV2
            name: test2
            type: block
        initiators:
          - name: iqn.2003-01.org.linux-iscsi.client1:111
            auto_add_luns: false
            lun_mapping:
              - disk: test1
                lun_id: 0
          - name: iqn.2003-01.org.linux-iscsi.client2:222
            auto_add_luns: false
            lun_mapping:
              - disk: test2
                lun_id: 1
      - wwn: "iqn.1994-05.com.redhat:portb"
        disks:
          - path: /dev/c7vg/LV1
            name: test1
            type: block
          - path: /dev/c7vg/LV2
            name: test2
            type: block
        initiators:
          - name: iqn.2003-01.org.linux-iscsi.client1:111
            auto_add_luns: false
            lun_mapping:
              - disk: test1
                lun_id: 0
          - name: iqn.2003-01.org.linux-iscsi.client2:222
            auto_add_luns: false
            lun_mapping:
              - disk: test2
                lun_id: 1

with the result that should look like this in targetcli:

o- iscsi ............................................................ [Targets: 2]
  o- iqn.1994-05.com.redhat:porta ...................................... [TPGs: 1]
  | o- tpg1 ............................................... [no-gen-acls, no-auth]
  |   o- acls .......................................................... [ACLs: 2]
  |   | o- iqn.2003-01.org.linux-iscsi.client1:111 .............. [Mapped LUNs: 1]
  |   | | o- mapped_lun0 ................................. [lun0 block/test1 (rw)]
  |   | o- iqn.2003-01.org.linux-iscsi.client2:222 .............. [Mapped LUNs: 1]
  |   |   o- mapped_lun1 ................................. [lun1 block/test2 (rw)]
  |   o- luns .......................................................... [LUNs: 2]
  |   | o- lun0 ................ [block/test1 (/dev/c7vg/test) (default_tg_pt_gp)]
  |   | o- lun1 ............... [block/test2 (/dev/c7vg/test2) (default_tg_pt_gp)]
  |   o- portals .................................................... [Portals: 1]
  |     o- 0.0.0.0:3260 ..................................................... [OK]
  o- iqn.1994-05.com.redhat:portb ...................................... [TPGs: 1]
    o- tpg1 ............................................... [no-gen-acls, no-auth]
      o- acls .......................................................... [ACLs: 0]
      | o- iqn.2003-01.org.linux-iscsi.client1:111 .............. [Mapped LUNs: 1]
      | | o- mapped_lun0 ................................. [lun0 block/test1 (rw)]
      | o- iqn.2003-01.org.linux-iscsi.client2:222 .............. [Mapped LUNs: 1]
      |   o- mapped_lun1 ................................. [lun1 block/test2 (rw)]
      o- luns .......................................................... [LUNs: 2]
      | o- lun0 ............... [block/test2 (/dev/c7vg/test2) (default_tg_pt_gp)]
      | o- lun1 ................ [block/test1 (/dev/c7vg/test) (default_tg_pt_gp)]
      o- portals .................................................... [Portals: 1]
        o- 0.0.0.0:3260 ..................................................... [OK]

NOTE: Above is just example on how this might look like in future and some details for variables in ansible may change, the expected output from targetcli ls is "desired outcome".

If you are OK with giving me some time (I think that I should have time to get some testing code by the end of this month) then I will prepare the code in separate branch and let you know once it is ready to be tested - changes will be in both ondrejhome.targetcli and ondrejhome.targetcli-modules. Therefore I want to ask if you are OK to test code that I will prepare during the month and give me feedback if that works for your use case? (simple yes/no is OK ;) )

@eggzotic
Copy link
Author

Hi Ondrej, yes that's exactly what I was hoping for :-) Thanks for confirming that it cannot do it now - at least I was not missing something. Sure I would be happy to test it when you have it ready. Just to clarify: will it be possible to supply the "wwn" values at run time, e.g. from a previously registered variable? That would really be perfect if we could?

@OndrejHome
Copy link
Owner

Just to clarify: will it be possible to supply the "wwn" values at run time, e.g. from a previously registered variable? That would really be perfect if we could?

I think it should be possible, have a look at following two examples that produces same output. In first one everything is specified manually, in second one the wwn_list is list of WWNs that will share same disks configuration. The iscsi_targets nested structure is generated in pre_tasks by set_fact module.

Example 1 (manually input everything):

- hosts: localhost
  roles:
    - { role: ondrejhome.targetcli }
  vars:
    iscsi_targets:
      - wwn: "iqn.1994-05.com.redhat:porta"
        disks:
          - path: /dev/c7vg/test
            name: test1
            type: block
          - path: /dev/c7vg/test2
            name: test2
            type: block
      - wwn: "iqn.1994-05.com.redhat:portb"
        disks:
          - path: /dev/c7vg/test
            name: test1
            type: block
          - path: /dev/c7vg/test2
            name: test2
            type: block
      - wwn: "iqn.1994-05.com.redhat:portc"
        disks:
          - path: /dev/c7vg/test
            name: test1
            type: block
          - path: /dev/c7vg/test2
            name: test2
            type: block

example 2 (generate same configuration for list of WWNs):

- hosts: localhost
  roles:
    - { role: ondrejhome.targetcli }
  vars:
    iscsi_targets: []
    tmpl_disks:
      - path: /dev/c7vg/test
        name: test1
        type: block
      - path: /dev/c7vg/test2
        name: test2
        type: block
    wwn_list:
      - "iqn.1994-05.com.redhat:porta"
      - "iqn.1994-05.com.redhat:portb"
      - "iqn.1994-05.com.redhat:portc"
  pre_tasks:
  - name: generate iscsi_targets variable
    set_fact:
      iscsi_targets: "{{ iscsi_targets + [{'wwn':item, 'disks':tmpl_disks }}"
    loop: "{{ wwn_list }}"

I will later add the 'example 2' into README for the targetcli role as it looks practical for large deployments with very similar/templated configuration.

@eggzotic
Copy link
Author

Very nice - thanks Ondrej - look forward to it :-)

@OndrejHome
Copy link
Owner

Update on progress:

  • targetcli_iscsi_acl and targetcli_iscsi_lun now supports parameter auto_add_luns which defaults to True (current behaviour)
  • to implement the individual mapped LUNs I plan to create targetcli_iscsi_acl_mapped_lun module that will handle adding/removing mapped luns to/from existing ACLs within target
  • once new module is ready I will try to integrate that into the ondrejhome.targetcli role

No significant code for testing yet, but I mostly got the code-level idea on what I need to do next. Will let you know once the new module is done at which point I think there will some code that can be tested out. Stay tuned on more updates probably this or next weekend.

@eggzotic
Copy link
Author

Yes, that targetcli_iscsi_acl_mapped_lun module fits with how I'd like to use it.

OndrejHome added a commit to OndrejHome/ansible.targetcli that referenced this issue Oct 4, 2021
WARNING: this is breaking change as the format of 'initiators' has
changed.

Motivation for this change was OndrejHome/ansible.targetcli-modules#5

To be able to use this new format the relevant
OndrejHome.targetcli-modules are needed.

Known issues: the cluster configuration use case is broken at this time.
@OndrejHome
Copy link
Owner

Hi Richard,

I have finally some code that can be tested :)
You will need develop version of both OndrejHome.targetcli and OndrejHome.targetcli-modules.

Your use case should be covered by Example C in https://github.com/OndrejHome/ansible.targetcli/tree/develop README.

When you will have time please let me know if this works for you. I have still few things on my TODO list for this change before it can make it into master - most significant one is that makes this a broken change due to way how initiators were just a list before and I have not yet figured out if there is any magic that would accept also the previous format.

I expect to get to this probably next week or next weekend.

@eggzotic
Copy link
Author

Hi Ondrej, hey sorry I have not got to testing this yet. Hopefully this week it will happen. Thanks for your work though - looks good so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants