[sos-devel] [PATCH] sosreport: Accept commas, period and alphas in the case number

[Bryn M. Reeves]

On Fri, Jul 11, 2014 at 11:12:35AM +0530, Aruna Balakrishnaiah wrote:
> In our existing ticket model we use all those chars like 123,7RN,43
> so its nice to have this format.
> 
> If not, can we atleast have alphas?

OK, so this is the type of major user-visible policy change that really
needs to be discussed on the list so that we can form a consensus before
going ahead with code changes.

To date the users of sos have only had a need for numerical ticket
identifiers and if we're going to move away from that there are other
considerations we should weigh up first.

In no particular order:

- The ticket-number field is encoded in the file names sos generates
  o What characters are permissible in all supported file systems?
  o Should we further restrict the set to ensure compatibility with
    other interchange file systems, e.g. FAT?

- If we're allowing non-numeric ticket/case identifiers then it's not
  really appropriate to call the option 'ticket-number' so we'll need
  to come up with an appropriate name and update all the
  documentation.

- Our current directory/tarball names are a bit unweildy and hard to
  parse visually. If we're going to make changes here we should get
  them all done together to minimize the number of variations and to
  keep user disruption to a minimum.

- Few users actually seem to use the ticket number field today (in
  a not-very-scientific-sample of reports I have lying around about
  30% had a valid case identifier in this field).

- Is it a ticket number, a case identifier, an incident #? Differnt
  support organisations have different terminologies and different
  validation rules: should this be under policy control? [note: a
  major complication with this is that to date we have not made any
  command line options controllable via policy. We don't currently
  have a mechanism to make that work and it would require quite a
  lot of reorganisation to fit into the current structure of the
  sosreport command.]

So I think this needs further discussion and consideration before
we can come to an agreement. Given that a lot of the contributors
today are via GitHub I think opening an issue there for discussion
is the best way forwards.

Regards,
Bryn.