esigler / lita-locker

Locking, unlocking shared resource handler for Lita.io

lita-locker

Locking, unlocking shared resource handler for lita.io.

Installation

Add lita-locker to your Lita instance's Gemfile:

gem "lita-locker"

Configuration

Optional attributes

• per_page - The number of items to show at once when listing labels or resources. Default: 10

Example

Lita.configure do |config|
  config.handlers.locker.per_page = 3

Usage

lita-locker allows you to define resources (such as a server, or Git repo), and labels (such as "production"). Labels can have multiple resources, and resources can be referenced by multiple labels. A label can only be locked if all of the resources it uses are available.

Examples

lock web                - Make something unavailable to others
unlock web              - Make something available to others
steal web               - Make yourself the owner of something locked by someone else
locker status web       - Show the current state of web

Locking, Unlocking, State

lock <label>                  - A basic reservation, with no time limit. Can have # comments afterwards.
unlock <label>                - Remove a reservation.  This can only be done by whomever made the request. Can have # comments afterwards.
steal <label>                 - Force removal of a reservation.  This can be done by anyone. Can have # comments afterwards.
locker give <label> to <user> - Transfer ownership of a lock to another user.  This can only be done by the lock's current owner. Can have # comments afterwards.

Status

locker status <label or resource>  - Show the current state of <label or resource>
locker list <username>             - Show what locks a user currently holds
locker log <label>                 - Show up to the last 10 activity log entries for <label>
locker observe <label>             - Get a notification when <label> becomes available
locker unobserve <label>           - Stop getting notifications when <label> becomes available

Queueing

lock <label>           - If <label> is already locked, adds you to a FIFO queue of pending reservations for <label>
locker dequeue <label> - Remove yourself from the queue for <label>

Labels

locker label list [--page N]               - List all labels
locker label create <name>                 - Create a label with <name>.
locker label delete <name>                 - Delete the label with <name>.  Clears all locks associated.
locker label add <resource> to <name>      - Adds <resource> to the list of things to lock/unlock for <name>
locker label remove <resource> from <name> - Removes <resource> from <name>
locker label show <name>                   - Show all resources for <name>

Resources

locker resource list [--page N]   - List all resources
locker resource create <name>     - Create a resource with <name>.  (Restricted to locker_admins group)
locker resource delete <name>     - Delete the resource with <name>.  Clears all locks associated.  (Restricted to locker_admins group)
locker resource show <name>       - Show the state of <name>

HTTP access

curl http://lita.example.com/locker/label/<name>    - Get current <name> status
curl http://lita.example.com/locker/resource/<name> - Get current <name> status

License

MIT

lita-locker's Issues

!locker resources list is unmanagable

So with like 500 resources, !locker resources list DDoSes a room. (And probably triggers flood protection on some adapter types). It should be batched one message, and preferably truncated.

Allow for a lock owner to transfer a lock to someone else

A lock owner sometimes needs to transfer a lock. Possible syntax could be:

!give artemis production to username

Thoughts:

• This should probably have the same behavior as !steal - avoid queue manipulation altogether.
• This wouldn't enable too much abuse, since if two people conspired to keep a lock, a 3rd person could still steal it.

There should be a way to see what locks someone has

Possible syntax suggestions?

`locker steal` should be an alias for `steal`

!steal should automatically reassign a lock

The code originally came from "unlock force", when it makes sense to just unlock something. But now that it's intention has changed slightly, it should remove the lock from the previous owner, (including a mention to the old owner), and assign it to whomever made the request.

Labels should be able to be renamed.

Deleting a resource does not remove it from associated labels

Reproduction steps:

1. Lita locker label create staging
2. Lita locker resource create staging_server
3. Lita locker label add staging_server to staging
4. Lita locker resource delete staging_server
5. Lita lock staging

Expected result:

(successful) staging locked

Actual result:

(failed) Label unable to be locked, blocked on:

Labels and resources should be able to have multiple entries added at once

Something like:

!locker label add resource1, resource2, resource3 to label

Reservations are desperately needed!

People need reservations!

Locker needs some comment syntax!

People should be able to do:

(unlock) some thing # Hey @person, here you go

Labels should prompt people with create syntax if they don't exist

Something like:

!lock some thing
> Sorry, that does not exist.  If you want to create it, do "!locker label create some thing"

Mention names would be super helpful

"some thing is locked by Some One" could do with @mention names if possible.

Labels should be suggested if there is a similar one

We should try edit-distance or something like that on labels, if they don't exist.

Something like:

!lock foobar stagin
> Sorry, that does not exist.  (Did you mean 'foobar staging'?)
!lock foobar staging

Avoid immediate duplicate positions in queue when a dequeue occurs

Avoid the following:

A: !lock foo
B: !lock foo
C: !lock foo
B: !lock foo
C: !locker dequeue foo

End result: foo: locked by A, queue: B, B

There is some duplicate protection logic, but it may not guard against the case where someone dequeues out from the middle of a pairing.

Steal should tattle

Steal should do a mention name / speak the previous owner name

Labels and resources should be able to be manipulated via API

So, rather than putting custom logic in for how to match labels and resources, I'd like to just expose an HTTP API, so that people can write their own matching crons (to do standard CRUD operations).

There should be a way to see what labels a resource is applied to

I should be able to figure out

resource: a

is used by

labels: 1,2,3

Label vs resource locking

It seems that the lock command takes only labels as its argument, yet according to the docs, a label cannot be unlocked unless all its resources are unlocked. How do individual resources become locked and unlocked? Also, why is resource creation/deletion restricted to :locker_admins but not label creation/deletion?

It should be possible to see the current status of a label

Right now, the only quick way is to try to grab the lock to see if it's taken.

Unlock emoji can be capitalized.

The regex should be made able to handle that. Who knew?

Locks should be able to have regexes?

It would be nice to lock groups of labels at once.

Something like:

!lock *
!lock web*
!lock *production

Or perhaps

!lockall production

Emoji should be optional

Not every transport supports Hipchat style emoji, so it should be optional.

Emoji needed for some of the unlock cases

There are a few places where a lock/unlock does not show emoji. This should be consistent with everywhere else.

Names should allow for - 's

Because names should allow for all sorts of things. https://github.com/esigler/lita-locker/blob/master/lib/locker/regex.rb#L11

Have backing-store cleanup scripts

For when we make breaking data model changes.

Locks should show when they were taken.

Tasty, tasty metadata.

Have a tracking / history log

So that room history isn't the only way to see lock behavior.

Locks should be able to be stalked

So that people can get status updates

Like:

!locker stalk some thing
!locker unstalk some thing

Have specialty resource types

Like Git repositories, so that repo/branchnames can be locked without having to create individual labels.

Locks should have "preferred" rooms

When there are enough labels, having everyone use a single room to lock/unlock gets rather noisy. Maybe we should have a "preferred" room for each label (with a default room for labels that don't have one)? And some sort of user reminder to prompt them not to lock except where it's preferred?

Allow the use of a wildcard operator in the status command

...so that I can see the status of multiple entities in a single command.

---

Background:

How it is now:
!locker status int1
int1 is locked by Alice (taken 1 hour ago)
!locker status int2
int2 is locked by Bob (taken 2 hours ago)
!locker status int3
int3 is locked by Carol (taken 3 hours ago)

How it should be:
!locker status int*
int1 is locked by Alice (taken 1 hour ago)
int2 is locked by Bob (taken 2 hours ago)

int3 is locked by Carol (taken 3 hours ago)

Definition of done:

• As a locker user, when I type "!locker status int*" in chat, I see the status of every locker label that matches that regular expression.