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

DLC: YAML output must adhere to parsing rules

Details

    • Bug
    • Resolution: Fixed
    • Critical
    • Lustre 2.7.0
    • None
    • 3
    • Dynamic LNET Configuration
    • 16975

    Description

      when CPT parameter is included in YAML output, the value should be enclosed in double quotes (").

      Currently

      net:
          - net: lo
            nid: 0@lo
            status: up
            tunables:
                peer_timeout: 0
                peer_credits: 0
                peer_buffer_credits: 0
                credits: 0
                CPT: [0,0]
      

      should be

      net:
          - net: lo
            nid: 0@lo
            status: up
            tunables:
                peer_timeout: 0
                peer_credits: 0
                peer_buffer_credits: 0
                credits: 0
                CPT: "[0,0]"
      

      Attachments

        Issue Links

          Activity

            [LU-6099] DLC: YAML output must adhere to parsing rules

            I see. Sorry, it appeared to me that CPT was a list/array (and valid YAML). If it's not, then yes, using quotes is fine. The application just has to parse the string.

            fzago Frank Zago (Inactive) added a comment - I see. Sorry, it appeared to me that CPT was a list/array (and valid YAML). If it's not, then yes, using quotes is fine. The application just has to parse the string.

            That means if you have over 10 CPTs, which I guess is entirely possible on multicore systems, you'll have something like:

            CPT:
              - 1
              - 2
              - 3
              - 4
              - 5
              - 6
              - 7
              - 8
              - 9
              - 10
            

            With larger number of CPTs, the output would be fairly large. It does give you the advantage of being converted into a python list, but the disadvantage is that you'll have fairly large output. And there will be no way to express a CPU range. For example "CPT: "[0-4]"

            Due to these reasons, I believe that the current solution advantages, outweigh the disadvantages.

            ashehata Amir Shehata (Inactive) added a comment - That means if you have over 10 CPTs, which I guess is entirely possible on multicore systems, you'll have something like: CPT: - 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 With larger number of CPTs, the output would be fairly large. It does give you the advantage of being converted into a python list, but the disadvantage is that you'll have fairly large output. And there will be no way to express a CPU range. For example "CPT: " [0-4] " Due to these reasons, I believe that the current solution advantages, outweigh the disadvantages.

            What about this?

              CPT: 
                - 0
                - 1
                - 2
            
            fzago Frank Zago (Inactive) added a comment - What about this? CPT: - 0 - 1 - 2

            There is no existing external tools that parse that output. So there is no backwards compatibility issue.

            the problem as I have explained in the patch is that the yaml 3rd party library that we use does not parse input such as [0,1...]. It has to be enclosed in double quotes. This causes a problem since the output can be without the double quotes, but if you take that output and try to pipe it into lnetctl again (ex: lnetctl import < config.yaml), it'll have a parse error.

            The requirement that the lnetclt export output has to be usable with lnetctl import, is higher priority than having the CPT parameter as parsable from python. Therefore the above solution was implemented.

            Another possible solution is to simply have the output as:

            CPT: 0,1,2
            

            However, that would parse in python as a string as well. So, you'll end up with the same issue.

            An easy way to deal with this is simply to parse out the CPT output into a list as below

            YAML output:
            
            net:
                - net: tcp
                  nid: 192.168.205.158@tcp
                  status: up
                  interfaces:
                      0: eth4
                  tunables:
                      peer_timeout: 180
                      peer_credits: 8
                      peer_buffer_credits: 0
                      clnetredits: 256
                  CPT: "[1,0]"
            
            Python Interpetation:
            
            {'net': [{'CPT': '[1,0]',
                      'interfaces': {0: 'eth4'},
                      'net': 'tcp',
                      'nid': '192.168.205.158@tcp',
                      'status': 'up',
                      'tunables': {'clnetredits': 256,
                                   'peer_buffer_credits': 0,
                                   'peer_credits': 8,
                                   'peer_timeout': 180}}]}
            
            if we assign the above python expression to a variable x, then you can do the following
            cpt_list = x['net'][0]['CPT'].replace('[', '').replace(']', '').split(',')
            
            then you can print items in the list by:
            
            int(cpt_list[0])
            
            You can also create a loop
            >>> for item in cpt_list:
            ...     print int(item)
            
            

            If you have a better solution please share it.

            ashehata Amir Shehata (Inactive) added a comment - There is no existing external tools that parse that output. So there is no backwards compatibility issue. the problem as I have explained in the patch is that the yaml 3rd party library that we use does not parse input such as [0,1...] . It has to be enclosed in double quotes. This causes a problem since the output can be without the double quotes, but if you take that output and try to pipe it into lnetctl again (ex: lnetctl import < config.yaml), it'll have a parse error. The requirement that the lnetclt export output has to be usable with lnetctl import, is higher priority than having the CPT parameter as parsable from python. Therefore the above solution was implemented. Another possible solution is to simply have the output as: CPT: 0,1,2 However, that would parse in python as a string as well. So, you'll end up with the same issue. An easy way to deal with this is simply to parse out the CPT output into a list as below YAML output: net: - net: tcp nid: 192.168.205.158@tcp status: up interfaces: 0: eth4 tunables: peer_timeout: 180 peer_credits: 8 peer_buffer_credits: 0 clnetredits: 256 CPT: "[1,0]" Python Interpetation: { 'net' : [{ 'CPT' : '[1,0]' , 'interfaces' : {0: 'eth4' }, 'net' : 'tcp' , 'nid' : '192.168.205.158@tcp' , 'status' : 'up' , 'tunables' : { 'clnetredits' : 256, 'peer_buffer_credits' : 0, 'peer_credits' : 8, 'peer_timeout' : 180}}]} if we assign the above python expression to a variable x, then you can do the following cpt_list = x[ 'net' ][0][ 'CPT' ].replace( '[' , '').replace(' ] ', ' ').split(' ,') then you can print items in the list by: int (cpt_list[0]) You can also create a loop >>> for item in cpt_list: ... print int (item) If you have a better solution please share it.

            I agree with Frank, that seems like an odd choice to me.

            morrone Christopher Morrone (Inactive) added a comment - I agree with Frank, that seems like an odd choice to me.

            I'm not affected by this, but that fix looks strange. It changes CPT from being an array to being a string. Is there any external tool parsing these files too? Because they're likely to break on that new input.

            Here's for instance how python decodes the test file before and after:

            {'net': [{'status': 'up', 'tunables': {'peer_timeout': 0, 'credits': 0, 'CPT': [0, 0], ...
            
            {'net': [{'status': 'up', 'tunables': {'peer_timeout': 0, 'credits': 0, 'CPT': '[0,0]', ...
            
            fzago Frank Zago (Inactive) added a comment - I'm not affected by this, but that fix looks strange. It changes CPT from being an array to being a string. Is there any external tool parsing these files too? Because they're likely to break on that new input. Here's for instance how python decodes the test file before and after: {'net': [{'status': 'up', 'tunables': {'peer_timeout': 0, 'credits': 0, 'CPT': [0, 0], ... {'net': [{'status': 'up', 'tunables': {'peer_timeout': 0, 'credits': 0, 'CPT': '[0,0]', ...

            Patch landed to Master.

            jlevi Jodi Levi (Inactive) added a comment - Patch landed to Master.

            Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/13304/
            Subject: LU-6099 lnet: correct YAML output
            Project: fs/lustre-release
            Branch: master
            Current Patch Set:
            Commit: 53cc2a1fe6befcd51826a9b42e8dff9cc33ee8a3

            gerrit Gerrit Updater added a comment - Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/13304/ Subject: LU-6099 lnet: correct YAML output Project: fs/lustre-release Branch: master Current Patch Set: Commit: 53cc2a1fe6befcd51826a9b42e8dff9cc33ee8a3

            Patch fixes the issue.

            simmonsja James A Simmons added a comment - Patch fixes the issue.

            Amir Shehata (amir.shehata@intel.com) uploaded a new patch: http://review.whamcloud.com/13304
            Subject: LU-6099 lnet: correct YAML output
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: 71abe659e67129280c8ec58c2782dcb6b1fb86d5

            gerrit Gerrit Updater added a comment - Amir Shehata (amir.shehata@intel.com) uploaded a new patch: http://review.whamcloud.com/13304 Subject: LU-6099 lnet: correct YAML output Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 71abe659e67129280c8ec58c2782dcb6b1fb86d5

            People

              ashehata Amir Shehata (Inactive)
              ashehata Amir Shehata (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: