parted: fix the ordering of list command

[aplanas]

The command parted -m -s {} print do not print the "Type" column,
but after the "File System" column print the name of the partition.

This point that the type of the partition cannot be extracted using
parted with machine parseable output.

[aplanas]

I submitted a patch to parted to add this field in the --machine format, as is really needed, but for now this change is relevant.

[cachedout]

Hmm. I'd like to know a little more about how this broke. Did the output of parted change at some point? If so, we need to account for both versions. cc: @techhat

[rallytime]

In addition to the question above, this change is breaking some tests: https://jenkinsci.saltstack.com/job/pr-kitchen-centos7-py2/job/PR-49804/2/

[aplanas]

@rallytime Thanks! I updated the tests. I run tox locally and I have some errors, but I do not think that are related to the patch.

[aplanas]

@cachedout Looks like that the parted coded didn't change. Looks an honest error in the salt code.

The core of the error is in the interpretation of the parted -m output. The human readable output in parted is different from the machine readable one. In the machine readable parted do not show the type, and optionally shows the name at the end (in the case of a gpt partition). Maybe in the tests is more clear:

f23d618#diff-ecd1221feb34cadb26ee8ac0fc57b66eL210

In the original test ext3 is in the type column. But in parted, type is for the partition type, as primary, extended or logical. Something that is clearly stated in the human readable output:

Model: ATA ST2000DM001-9YN1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  2155MB  2154MB  primary  linux-swap(v1)  type=82
 2      2155MB  45.1GB  43.0GB  primary  btrfs           boot, type=83
 3      45.1GB  2000GB  1955GB  primary  xfs             type=83

Also in the original test the file system field is empty, where ext3 is naturally expected.

You can inspect the parted code that deal with this logic here:

https://github.com/Distrotech/parted/blob/distrotech-parted/parted/parted.c#L1240

I submitted a patch to parted to add the type column, but I am not sure if it will be reviewed:

https://alioth-lists.debian.net/pipermail/parted-devel/2018-September/005312.html

Note also that I only inspected the code for Debian and openSUSE, I did not check Fedora or Arch. But the tests suggest that there is no any other unkown patch attached to any distribution that add the correct partition type in the parted output.

[aplanas]

Is there anything here that I can do to help the patch?

[rallytime]

Same thing on this one - our test runner set up had some issues, so I restarted some of them here. @garethgreenaway Can you take a look here?

[cachedout]

@aplanas Thank you for the detailed explanation. It resolves my concerns. Once @garethgreenaway reviews this, it should be fine to merge.

[aplanas]

The bug is a bit deeper, as the field list depends on the partition type. For msdos partitions this order is different. I will wait the review of this one (that address the gpt case, as expressed in the tests cases) before submitting the code for the msdos case (and adding tests cases for it)

[rallytime]

@aplanas This has been approved now. I am not sure from your comment - are you planning on making changes to this PR? Or did you want to make those changes in a follow up PR after this is merged?

[aplanas]

@rallytime No this PR, as the error is for a different partition type that the one in the tests.

I have a local branch with the fix, I am writing the tests, but I think that they belong to a different PR.

Thanks!

[rallytime]

@aplanas Sounds good! I'll get this merged in now. Thank you!