Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-2456

Dynamic LNet Config Main Development Work

Details

    • New Feature
    • Resolution: Fixed
    • Major
    • Lustre 2.7.0
    • Lustre 2.6.0
    • None
    • 5798

    Description

      This ticket has been created to track the main development work for the Dynamic LNet Config project.

      Attachments

        1. dlc_api.patch
          14 kB
        2. DLC_FTP.docx
          157 kB
        3. DLC_User_doc.pdf
          101 kB
        4. Dynamic LNet Config.pdf
          55 kB
        5. Dynamic LNet Config Test Plan.pdf
          293 kB
        6. l_dlc.patch
          5 kB

        Issue Links

          Activity

            [LU-2456] Dynamic LNet Config Main Development Work
            simmonsja James A Simmons added a comment - http://review.whamcloud.com/#/c/9830 http://review.whamcloud.com/#/c/9831 http://review.whamcloud.com/#/c/9832 http://review.whamcloud.com/#/c/8021 http://review.whamcloud.com/#/c/8022 http://review.whamcloud.com/#/c/8023 http://review.whamcloud.com/#/c/8025 http://review.whamcloud.com/#/c/8026 http://review.whamcloud.com/#/c/8027 http://review.whamcloud.com/#/c/8028

            suggestions about dlc APIs based on discussion in Miami

            liang Liang Zhen (Inactive) added a comment - suggestions about dlc APIs based on discussion in Miami
            liang Liang Zhen (Inactive) added a comment - comments for DLC patch http://review.whamcloud.com/#/c/9785/

            I'm up for a call. I am free after 3:30 PST today, or most of the day tomorrow.

            morrone Christopher Morrone (Inactive) added a comment - I'm up for a call. I am free after 3:30 PST today, or most of the day tomorrow.

            I have a recommendation. I'm finding that progressing on the project with this form of communication is inefficient. Would you agree for a skype/phone meeting, where we can hash out the different points of view. I would say that we can call a meeting with yourself, Doug Oucharek, Andreas and myself. Does that sound like a reasonable plan?

            ashehata Amir Shehata (Inactive) added a comment - I have a recommendation. I'm finding that progressing on the project with this form of communication is inefficient. Would you agree for a skype/phone meeting, where we can hash out the different points of view. I would say that we can call a meeting with yourself, Doug Oucharek, Andreas and myself. Does that sound like a reasonable plan?

            User Documentation as exported from the internal Wiki

            ashehata Amir Shehata (Inactive) added a comment - User Documentation as exported from the internal Wiki
            ashehata Amir Shehata (Inactive) added a comment - - edited

            The CLI

            lnetctl <cmd> <entity> [parameters]

            except that we use optional parameters to pass in the different parameters. The decision is to get away from positional parameters.

            ex:

            add route --net tcp0 --gateway 10.1.1.2@tcp1 --hop 1 --priority 0

            Also please note that the examples you gave above are not consistent form. In some cases you have

            lnetctl <command> <object>
            ex: lnetctl set small_buffers 1000

            and in other cases you have

            lnetctl OBJECT COMMAND
            ex: lnetctl network add o2ib0 dev ib0

            In my opinion, I think a consistent form makes it easier to get more familiar with the command line.

            I agree that "del file" with regards to enabling/disabling routing might be confusing. Here is my suggestion.

            To reset all router buffers to default values the yaml file that you feed to the del command would look like:

            • buffer

            If you add other parameters under buffer they will be ignored. For example:

            • buffer:
              tiny: 2000

            it'll still reset the buffer to the default values.

            To disable routing the yaml file would include:

            • routing

            This way you can take the exact same YAML file feed it to any of the commands and they will get processed correctly. Parameters that are meaningless to the command are ignored.

            With your suggestion:
            lnetctl import myfinefile.yaml

            What operations do we do on myfinefile.yaml? What is contained in the yaml file?

            That's why you explicitly tell the utility what to do on the yaml file (add, del or show)

            ashehata Amir Shehata (Inactive) added a comment - - edited The CLI lnetctl <cmd> <entity> [parameters] except that we use optional parameters to pass in the different parameters. The decision is to get away from positional parameters. ex: add route --net tcp0 --gateway 10.1.1.2@tcp1 --hop 1 --priority 0 Also please note that the examples you gave above are not consistent form. In some cases you have lnetctl <command> <object> ex: lnetctl set small_buffers 1000 and in other cases you have lnetctl OBJECT COMMAND ex: lnetctl network add o2ib0 dev ib0 In my opinion, I think a consistent form makes it easier to get more familiar with the command line. I agree that "del file" with regards to enabling/disabling routing might be confusing. Here is my suggestion. To reset all router buffers to default values the yaml file that you feed to the del command would look like: buffer If you add other parameters under buffer they will be ignored. For example: buffer: tiny: 2000 it'll still reset the buffer to the default values. To disable routing the yaml file would include: routing This way you can take the exact same YAML file feed it to any of the commands and they will get processed correctly. Parameters that are meaningless to the command are ignored. With your suggestion: lnetctl import myfinefile.yaml What operations do we do on myfinefile.yaml? What is contained in the yaml file? That's why you explicitly tell the utility what to do on the yaml file (add, del or show)

            I would like to argue again for seeing an updated DLC design document attached to this ticket (or in confluence or something).

            One thing I'm realizing is that I'm not particularly in favor of the command line design. The design currently looks something like this:

            lnetcfg {add|del|show} OBJECT [options]

            I think that is fundamentally backwards. Instead, we should take inspiration from the linux "ip" command, and other commands like git. The basic model should be:

            So for instance the first line of the ip command's man page synopsis shows this:

            ip [ OPTIONS ] OBJECT { COMMAND | help }

            That is the style that I think we want to emulate for the new command. So some examples might be:

            lnetctl network add o2ib0 dev ib0
            lnetctl route add o2ib9 routers 192.168.121.[160-163]@o2ib2
            

            If there are global variables that we want to set, it is reasonable to use global get/set commands. For instance:

            lnetctl set small_buffers 1000
            lnetctl set medium_buffers 1000
            lnetctl set large_buffers 1000
            lnetctl set routing 1
            lnetctl set routing 0
            

            For handling yaml files, I think the original plan is kind of ugly:

            lnetctl add file --name <yaml file name>
            lnetctl del file --name <yaml file name>
            

            I can't even really wrap my head around how the "del file" behavior would even work. For instance if I have this section in my yaml file:

            buffer:
                    enable: 0
            

            and then I feed it "del file", do I wind up with routing enabled? If I have this:

            buffer:
                    tiny: 2000
            

            What does "del file" do??? If I can't figure this out, there is no way that a sysadmin will.

            And "buffer" is the wrong name for that yaml section as well. But I digress.

            A better command line for this might look like:

            lnetctl import < myfinefile.yaml
            lnetctl import myfinefile.yaml
            lnetctl export > backupsettings.yaml
            lnetctl export backupsettings.yaml
            
            morrone Christopher Morrone (Inactive) added a comment - I would like to argue again for seeing an updated DLC design document attached to this ticket (or in confluence or something). One thing I'm realizing is that I'm not particularly in favor of the command line design. The design currently looks something like this: lnetcfg {add|del|show} OBJECT [options] I think that is fundamentally backwards. Instead, we should take inspiration from the linux "ip" command, and other commands like git. The basic model should be: So for instance the first line of the ip command's man page synopsis shows this: ip [ OPTIONS ] OBJECT { COMMAND | help } That is the style that I think we want to emulate for the new command. So some examples might be: lnetctl network add o2ib0 dev ib0 lnetctl route add o2ib9 routers 192.168.121.[160-163]@o2ib2 If there are global variables that we want to set, it is reasonable to use global get/set commands. For instance: lnetctl set small_buffers 1000 lnetctl set medium_buffers 1000 lnetctl set large_buffers 1000 lnetctl set routing 1 lnetctl set routing 0 For handling yaml files, I think the original plan is kind of ugly: lnetctl add file --name <yaml file name> lnetctl del file --name <yaml file name> I can't even really wrap my head around how the "del file" behavior would even work. For instance if I have this section in my yaml file: buffer: enable: 0 and then I feed it "del file", do I wind up with routing enabled? If I have this: buffer: tiny: 2000 What does "del file" do??? If I can't figure this out, there is no way that a sysadmin will. And "buffer" is the wrong name for that yaml section as well. But I digress. A better command line for this might look like: lnetctl import < myfinefile.yaml lnetctl import myfinefile.yaml lnetctl export > backupsettings.yaml lnetctl export backupsettings.yaml

            That is correct. I'm almost done my updates to the DLC patches.

            ashehata Amir Shehata (Inactive) added a comment - That is correct. I'm almost done my updates to the DLC patches.
            rread Robert Read added a comment -

            Agreed, and I believe Amir does intend to create a new config utility in lnet. The difference is he now plans to use the same cli parser library that lctl uses, instead of using the new one he originally wrote for DLC.

            rread Robert Read added a comment - Agreed, and I believe Amir does intend to create a new config utility in lnet. The difference is he now plans to use the same cli parser library that lctl uses, instead of using the new one he originally wrote for DLC.

            OK, granted.

            Still, I am not not in favor of adding this to lctl. I would like to see it as a separate command under the lnet subdirectory somewhere (lnet/utils, for instance).

            morrone Christopher Morrone (Inactive) added a comment - OK, granted. Still, I am not not in favor of adding this to lctl. I would like to see it as a separate command under the lnet subdirectory somewhere (lnet/utils, for instance).

            People

              ashehata Amir Shehata (Inactive)
              doug Doug Oucharek (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              20 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: