friendly naming pattern not providing time

[slashdd]

Not providing time may be challenging for customer sending multiple sosreport archive in the same day for the same host, to know the order of creation.

Yes, we can workaround it with label (e.g. 1strun, 2ndrun, ....) but it's not as efficient as the time.

Time exist in legacy mode, but has been dropped in 'friendly' mode.
Which I assume the decision was made to restrict the amount of digit in the archive name.

What about adding the time back in 'HHMM' format and rename sosreport to sos, which anyway IIUC, 4.0 will be called sos subcommand instead of sosreport, so that would stay align with current 4.0 development plan.

Removing 'report' == - 6 digits
Adding HHMM == + 4digits

The archive name benefit of 2 digits less longer with that approach, and the naming to be more valuable IMHO.

(e.g.sos-tux-mylabel-123456-2017-12-24-1455-ezcfcop.tar.xz')

[BryanQuigley]

We discussed this internally and I don't know if minute accuracy makes sense.

My counter proposal was to just take the minutes in the day and divide by 15 - to always get a 2 digit number for that day. That way it's just +2digits and implies about the accuracy of what time period we are collecting.

Also, any reason to not use the checksum hash instead of random?

[TurboTurtle]

Not providing time may be challenging for customer sending multiple sosreport archive in the same day for the same host, to know the order of creation.

ls -l?

Time exist in legacy mode, but has been dropped in 'friendly' mode.
Which I assume the decision was made to restrict the amount of digit in the archive name.

What about adding the time back in 'HHMM' format and rename sosreport to sos, which anyway IIUC, 4.0 will be called sos subcommand instead of sosreport, so that would stay align with current 4.0 development plan.

The binary will be renamed. The project has always been called 'sos'. With the different sub commands planned, I would imagine we'd keep the identifier in the name of whatever we're outputting (e.g. sosreport, soscollector, sosdiff)

My counter proposal was to just take the minutes in the day and divide by 15 - to always get a 2 digit number for that day.

For sosreports taken within the same 15-minute block, would that not land us right back here?

Also, any reason to not use the checksum hash instead of random?

Length. The name pattern change was initiated due to archive names that were really unfriendly on the eyes due to the timestamp used. A checksum hash is making that situation worse, imo.

[slashdd]

If you transfer the sosreport archive from it's original place, the timestamp shown in ls for the given archive will change. Which makelsuseless unless you are on the orginal machine.

Where it has been created:
-rw------- 1 root root 2183052 Feb 20 14:40 sosreport-....tar.xz

After the transfert to another machine, it wil take the time of the other machine and so on.
-rw------- 1 USER GROUP 2183052 Feb 20 14:42 sosreport-....tar.xz

If you don't transfert them in the right order, extra reading and care need to be taken to make sure you put back the archives in the right order of time. It's not impossible, but it can clearly become an annoyance.

[TurboTurtle]

$ date
Thu 20 Feb 2020 02:48:24 PM EST
[jake@cadia [...]]$ ls -l
total 55604
-rw-rw-r--. 1 jake jake 56937328 Feb 13 11:27 sosreport-[...]-2020-02-13-[...].tar.xz
                                    ^^^^

[jake@cadia [...]]$ stat sosreport-[...]-2020-02-13-[...].tar.xz
  File: sosreport-[...]-2020-02-13-[...].tar.xz
  Size: 56937328  	Blocks: 111208     IO Block: 4096   regular file
Device: fd04h/64772d	Inode: 68331688    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    jake)   Gid: ( 1000/    jake)
Context: unconfined_u:object_r:etc_runtime_t:s0
Access: 2020-02-20 14:31:38.807842795 -0500  <=== I just touched it recently
Modify: 2020-02-13 11:27:01.000000000 -0500  <=== User created, ls reports this
Change: 2020-02-18 14:36:23.636475420 -0500  
 Birth: 2020-02-18 14:35:55.085305230 -0500  <=== When I pulled it to my work system

[TurboTurtle]

FWIW, if the Ubuntu contributors/users really want a timestamp of any kind, you can make it a policy-specific one by just changing name_pattern = 'friendly' to whatever custom style/template you land on in the policy.

The change from legacy to friendly for RH was a bit of a mixed bag - the majority of people wanted it and responded positively, but a loud minority were against any changes at all to the name pattern - but internally we're all settled on it and fine now. I would not want to disrupt that again.

[slashdd]

Original host from where sosreport has been generated

Access: 2020-02-20 20:05:20.628225069 +0000
Modify: 2020-02-20 20:03:50.175131497 +0000
Change: 2020-02-20 20:03:50.807139138 +0000
Birth: -

Wait a couple of minutes, then sftp the archive to our ftp and then downloading the archive from the ftp to a analysis system:

Access: 2020-02-20 15:06:16.927856528 -0500
Modify: 2020-02-20 15:06:16.915856352 -0500
Change: 2020-02-20 15:06:17.327862376 -0500
Birth: -

We completely loose track of the time and if created and downloaded in diff TZ it add an extra layer of distraction.

I really don't think we should drop the time at all IMHO (minus the second, which I don't think add any value) Having the time in the archive name is quick and easy reference.

[slashdd]

We will evaluate internally what are the next step, if we stick to friendly mode or adapt name_pattern in ubuntu policy.

Thanks for the context @TurboTurtle