Proposal: new getter: get_filesystems

[decoupca]

Based on this discussion.

I propose a new getter called get_filesystems.

Example data structure for IOS:

{
    'flash:': {
        'capacity': 1621966848,
        'space_used': 878018560,
        'space_remaining': 743948288,
        'is_primary': True, # derived from `show file systems`, denoted with asterisk
        'mount_point': 'flash:', # Redundant for IOS but useful for junos or others
        'flags': 'rw',
        'file_list': [
            {
                'file_name': 'cat3k_caa-universalk9.16.12.05b.SPA.bin',
                'size': 480018036,
                'mtime': '2021-08-12T23:53:40Z', # Should be a datetime object
                'mode': '-rw-',
            },
            {
                ...
            }
        ],
    },
    'crashinfo:': {
        'capacity': 248354816,
        'space_used': 19483648,
        'space_free': 228871168,
        'is_primary': False,
        'mount_point': 'crashinfo:',
        'flags': 'rw',
        'file_list': [
            {
                'file_name': 'last_systemreport_log',
                'size': 357,
                'mtime': '2021-08-12T23:53:40Z',
                'mode': '-rwx',
            },
            {
                ...
            }
        ]
    }
}

I don't have enough experience with Junos, Arista, etc. to know if/how they could support this data structure. IMO the most important values are the filesystem name, its capacity, space used, and its flags (rw/ro/etc). The file listing would be nice but I would give that up if it's not feasible. Also some way to determine which filesystem is "primary", i.e., which is used for main storage of images, etc.

[ktbyers]

Okay, let me see if I can look on some other platforms (Junos, NX-OS, EOS, IOS-XR and see what they have here).

[ktbyers]

@decoupca Just verifying you really want to do this? I can get you access into the other platforms (if you are willing to do the work).

Here is what needs done:

1. Data structure format agreed upon
2. Implementation for at least 3 of the napalm community drivers.
3. Add reasonable set of test-code / test-cases for the platforms where this is implemented at.
4. Update documentation (or verify documentation automatically picked up this new getter).

[ktbyers]

I don't think we should do a list of all the files. On platforms that are linux based, I think it will be annoying/time consuming to figure out and process all of the files in the filesystem).

Do you know what the meaning of is_primary is (i.e. what does that mean physically)? Are the non-primary file-systems just using space from the primary file-system (and implemented out of it somehow)?

[decoupca]

I don't think we should do a list of all the files. On platforms that are linux based, I think it will be annoying/time consuming to figure out and process all of the files in the filesystem).

Agreed.

Do you know what the meaning of is_primary is (i.e. what does that mean physically)? Are the non-primary file-systems just using space from the primary file-system (and implemented out of it somehow)?

I wanted an easy way to tell what filesystem it's booting from, and what filesystem would be appropriate for storing extra files on. Cisco would be easy, either "flash:" or "bootflash:" Non-primary filesystems might be external storage cards (not sure if vendors are still doing those), or like how Junos presents a bunch of filesystems/mount points, all likely based on a single root FS.

Given that all vendors handle storage very differently, I think we should take our time in deciding on a data structure. The one I presented was more of a first draft, but I feel like it needs refinement. I feel confident that the data structure should include name, total size, bytes used, and bytes free, and its access mode (rw, ro, wo). Beyond that I'm less confident and open to suggestions.

Just verifying you really want to do this?

I don't have the bandwidth to implement this on my own right now. I'd like to, and I may have time down the road, but I don't want to roadblock this if you or someone else can implement it sooner.

[network-shark]

I like this new getter approach , but I would be against automatically loading it with get_facts() . This would slow down salt which invokes get_facts a couple of times on startup. I have already build some of this functionality for iOS XE . From the example above. Do you think it is useful to parse all files in the flash by default and put the data in the dict ? On IOS XE there are folders and other files which I am actually don't know why thery are there :) . I am only searching / detecting for binaries for example , but this behaviour only make sene for iOS XE , I don't have a lot of knowledge on other systems.

[decoupca]

against automatically loading it with get_facts()

Agreed.

Do you think it is useful to parse all files in the flash by default and put the data in the dict ?

I'm with Kirk here, I think a file listing would be too much. Might be appropriate for yet another getter, say get_filesystems_detail(), but IMO we should keep it simple for now and just include the basics.

[mirceaulinic]

against automatically loading it with get_facts()

Agreed.

Same.

Might be appropriate for yet another getter, say get_filesystems_detail()

Or get_filesystems(detailed=True) 😄 (which can be added later)