Current:

Available Commands:
  binding     Create a new queue <--
  exchange    Create a new exchange
  queue       Create a new queue

Expected:

Available Commands:
  binding     Create a new binding <--
  exchange    Create a new exchange
  queue       Create a new queue

All messages requeue in spite of requeue flag because requeue field has been removed from Management UI and ackmode is ack_requeue_true.

ackmode determines whether the messages will be removed from the queue. If ackmode is ack_requeue_true or reject_requeue_true they will be requeued - if ackmode is ack_requeue_false or reject_requeue_false they will be removed.

At the moment, buneary cannot publish messages with headers. Sending messages with headers should be enabled by implementing a --headers or --header option.

There are two possibilities here:

• Either let the user pass a list of key-value pairs to the flag: --headers="key1=val1,key2=val2"
• Or let the user specify multiple flags: --header key1=val1 --header key2=val2

@aligator PTAL

At the moment, any error produced by functions in the standard library or third-party packages are returned without context. Additional context should be added to provide more information about when the error occured using fmt.Errorf:

if err != nil {
    return fmt.Errorf("failed to make coffee: %s", err.Error())
}

buneary's interactive mode seems to have some flaws on macOS. To reproduce, run any command that requires you to provide RabbitMQ credentials:

buneary get exchanges localhost
... will wait forever ...

You won't be prompted for your credentials at all. Instead, nothing seems to happen.

Tested on macOS 11.1.

There should be a command for reading messages from a given queue. The command syntax should look as follows:

$ buneary get messages <QUEUE NAME>

This command should return a list (or actually table) of messages. Also, there should be the buneary get message command for detailed message information:

$ buneary get message [<QUEUE NAME>] <MESSAGE ID OR SOMETHING LIKE THAT>

Not sure if the queue name is required from a technical perspective. This command should return the message body and headers.

At the moment, buneary checks if the number of given arguments matches the required number of arguments. However, there's an edge case where a command does exist, the number of arguments doesn't match and buneary won't complain (but neither will do anything).

Correct:

$ buneary create exchange localhost my-exchange direct

Wrong:

$ buneary create localhost exchange my-exchange direct

There won't be an error in the second case - probably because the buneary create command exists but does not prescribe the number of arguments or require a subcommand (localhost is not a subcommand, but exchange is).

After running a command like buneary create exchange, there should be a success message indicating that the resource has been created.

The output could look like this:

$ buneary create exchange localhost my-exchange direct
Successfully created exchange my-exchange.

As a buneary user, I want to be able to display resource information using the buneary get command. Since buneary strives to provide a kubectl-like interface, I'm planning to implement it as follows:

• buneary get <ADDRESS> <RESOURCE TYPE> - e.g. buneary get localhost queues - returns a table containing all the items of the resources type.
• buneary get <ADDRESS> <RESOURCE TYPE> <NAME> - e.g. buneary get localhost queue my-queue - returns information for a single item.

Both command forms should return the same information per item. Note that the first form uses the plural and the second form uses the singular of the resource type (queues vs. queue). This is different from kubectl, but I consider it to be cleaner.

The supported resource types will be queues, exchanges, bindings and maybe messages.

For further information for a resource item, a command like buneary describe analogous to kubectl describe could make sense if needed.

At the moment, there's no -v flag for printing version information but only the version sub-command instead.

The -v flag can be enabled by assigning the main.version variable to the Version field of the root command.

buneary commands can become quite long, partially because the host - which mostly corresponds to localhost for local development - has to be specified in each command:

$ buneary create exchange localhost my-exchange topic

Introducing a lo abbreviation could shorten this a bit.

$ buneary create exchange lo my-exchange topic

Internally, it would be sufficient to check whether the address is "lo" and change it to "localhost" if it is.