CLI Create Ticket

[jasonjohnson]

Basic Operation

A command to create a ticket should be added to the CLI. We would eventually want to be able to perform other actions on tickets by ID or as a whole, so the command structure would be straightforward:

$ sl ticket create

We could add flags to the command directly:

Composing

$ sl ticket create --title="Help me! My HDD is dead!"

Once invoked, we could observe the $EDITOR environment variable or search for a sane editor in the users path (nano, vim, emacs, etc.) and use it to compose the body of the ticket. The output of the ticket could simply be the ticket ID for later use with an 'update' command or for finding the thread in the portal.

$ sl ticket create
(...nano...)
Ticket created: #12345

Without a Title Flag

It is possible the message composition could prefer the first line or first sentence of the message as its title to avoid requiring the user to specify beforehand.

If the user has provided a title flag, however, the simplest method of exemplifying usage would be to correctly format the editor using the title they provided. Place their cursor on the 2nd line following the title to begin the ticket body.

Query the Metadata Service

When the command is invoked, we could attempt to query the metadata service to see if the invocation has occurred on a host on our network. If it has we can include basic information, such as current hostname and network configuration, services running, etc.

This data would not be silently gathered, rather populated in the $EDITOR during ticket composition. This intermediate step would allow the customer to suppress any information they did not believe pertained to the trouble they are experiencing.

Sample $EDITOR Session

sl ticket create --title="Help me! My HDD is dead!"

1. Locate suitable editor: /usr/bin/nano
2. Query metadata service: Success, scan for extra stuff.
3. Scan machine for critical metrics: basic network and disk utilization.
4. Launch & populate editor:

Help me! My HDD is dead!

I've been having issues with /dev/sdb and it seems as
though the drive has stopped responding entirely. I'm
assuming hardware failure but I would appreciate you
taking a look. Thank you!

--------------------------------------------------
Below is information which may assist our support
techs. Nothing has been transmitted at this point.
Feel free to remove information now.
--------------------------------------------------
Hostname: host-001.example.com
IP Address: 127.0.0.1
Filesystems:
     /dev/sda1    90M     52M     61%     /boot
     /dev/sda6    457G   7.6G     2%      /
(etc)

Upon closing,

Ticket created: #12345
$ 

[CrackerJackMack]

+1

[sudorandom]

+1

[follower46]

+1

[jasonjohnson]

Been participating in some conversations around what the rest of the "sl ticket" suite would look like. Something to consider:

$ sl ticket list
$ sl ticket list --status=closed
$ sl ticket update [ticket-id]
$ sl ticket close [ticket-id] --reason="Thank you! Fixed."
$ sl ticket attach [ticket-id] /tmp/screenshot.png

Also some interesting alternatives,

$ sl ticket create --title="My server's borked!" --hardware=54321
$ sl ticket create --title="My server's borked!" --hardware=app-17
$ sl ticket create --title="My server's borked!" --file=/tmp/screenshot.png

I'm hesitant to use object ID's of any sort in flags aside from the ticket ID unless the logic is fuzzy enough to accept things like short or fully-qualified host names.

Commands like "sl ticket update [ticket-id]" would take the user back into their $EDITOR session. This time, the body of the document would include the entire ticket history. They could apply their update to the very top and a simple diff on the before & after would reveal what they added.

[CrackerJackMack]

Instead of --reason you could probably just use --body or --response. This would also allow for you to set the respond to a single dash. This is the standard (unix) way of switching to stdin reading.

$ grep "ata0.1" /var/log/messages | sl ticket update [ticket-id] --body=-

I would also say that closing a ticket should be a flag to update. So to close a ticket without a response it would be sl ticket update --close --body=""

[briancline]

--body seems like the best fit. Input from stdin could also be detected and appended if a non-empty body is specified, or become the entire body otherwise.

[sudorandom]

There's some precedence for using stdin with creating messages in the message queue module of the CLI: https://github.com/softlayer/softlayer-python/blob/master/SoftLayer/CLI/modules/messaging.py#L315

[underscorephil]

Open/update should also include the --body switch to allow for easy integration with CLI scripts.

[anasouma]

fyi, talked to Phil, and I will be looking at starting implementing this.

[anasouma]

Things I've implemented so far. I will most likely fork and have someone review it if interested:
1 - Listing:

• sl ticket list -> returns all tickets
• sl ticket list --status=open-> returns all open tickets
• sl ticket list --status=closed -> returns all closed tickets
  2 - Summary:
  -sl ticket summary -> return a breakdown of all tickets
  3 - Details
  -sl ticket details xxxxx > details of a particular ticket, returns the last updated entry
  -sl ticket details xxxxx --updateCount=5 > details of a particular ticket, returns the last 5 updated entries
  4 - Creation
  -sl ticket subjects --> list all the subjects that can be used when creating a ticket
  -sl ticket create --subject=xxx --title="Need help respinning my OS" > will open a default editor for the body of the ticket
  -sl ticket create --subject=xxx --title="Need help respinning my OS" --body="xxx" -> can take body as input
  5 - Update
• sl ticket update xxxx --body="xxxx"
• sl ticket update xxxx -> reads from default editor

Things missing:
1 - attaching a file at creation or update
2 - attaching hardware id and password at ticket creation
3 - Closing a ticket... My understanding this is not supported. Only support can close a ticket. Am I mistaken?

Wissam

[anasouma]

Sorry about the formatting, reposting
1 - Listing:

sl ticket list -> returns all tickets
sl ticket list --status=open-> returns all open tickets
sl ticket list --status=closed -> returns all closed tickets 

2 - Summary:

sl ticket summary -> return a breakdown of all tickets 

3 - Details

sl ticket details xxxxx > details of a particular ticket, returns the last updated entry 
sl ticket details xxxxx --updateCount=5 > details of a particular ticket, returns the last 5 updated entries 

4 - Creation

sl ticket subjects --> list all the subjects that can be used when creating a ticket 
sl ticket create --subject=xxx --title="Need help respinning my OS" > will open a default editor for the body of the ticket 
sl ticket create --subject=xxx --title="Need help respinning my OS" --body="xxx" -> can take body as input 

5 - Update

sl ticket update xxxx --body="xxxx"
sl ticket update xxxx -> reads from default editor

[jasonjohnson]

Wow, that's excellent!

Yes, please push this up somewhere we can take it for a spin. I see you've forked it so feel free to push your changes up to a branch in your fork.

[anasouma]

Jason, should be under https://github.com/anasouma/softlayer-python/tree/TicketingSupport now.

[underscorephil]

Covered in PR #279

[underscorephil]

closing - resolved