Giter Club home page Giter Club logo

alice's Introduction

Alice

Official release post: http://willcodeforfoo.com/2009/07/13/announcing-alice/

http://alicetheapp.com.

As a queue server, RabbitMQ is super cool, but my company is hesitant to use it without a nice front-end or access to statistics about the server. So we set out to develop the latest RabbitMQ REST interface, Alice.

Alice is a RESTful interface to the RabbitMQ server that talks directly through erlang's native interface, epmd. The purely RESTful server responds to the same interface as the RabbitMQ's command-line interface and presents a native HTTP interface to the data. Alice is written with Mochiweb.

Quickstart

How to get started.


git clone git://github.com/auser/alice.git
cd alice
./start.sh

You can pass a rabbithost where your rabbitmq-server sits by passing the options rabbithost in the command-line, like so:


  ./start.sh -alice rabbithost "other.node.come"

Note, you may have to set your cookie when starting Alice with a remote node by the -setcookie flag:


  ./start.sh -alice rabbithost "other.node.com" -setcookie "mysecretcookie"

## Currently exposed RESTful routes
  /conn - Current connection information
  /exchanges - Current exchanges information
  /queues - Current queues
  /users - Current users
  /bindings - Current bindings
  /control - Access to the RabbitMQ control
  /permissions - Current permissions
  /vhosts - Current vhosts

These endpoints all are exposed with the four verbs (get, post, put, delete) and respond in the JSON format, (except the root / endpoint which responds with text/html).

Usage

Users


# List users
curl -i http://localhost:9999/users 
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:08:20 GMT
Content-Type: text/json
Content-Length: 19

{"users":["guest"]}

# Viewing a specific user
curl -i http://localhost:9999/users/guest
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:01:01 GMT
Content-Type: text/json
Content-Length: 17

{"users":"guest"}

# If the user is not a user:
curl -i http://localhost:9999/users/bob  
HTTP/1.1 400 Bad Request
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:01:20 GMT
Content-Type: text/json
Content-Length: 20

{"bob":"not a user"}

# Add a user
curl -i -XPOST \
        -d'{"username":"ari", "password":"weak password"}' \
        http://localhost:9999/users
        
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Thu, 16 Jul 2009 00:10:35 GMT
Content-Type: text/json
Content-Length: 25

{"users":["ari","guest"]}

# Deleting a user
curl -i -XDELETE  http://localhost:9999/users/ari
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:19:24 GMT
Content-Type: text/json
Content-Length: 19

{"users":["guest"]}

Notice that when we list the user that doesn't exist, bob from the second example above, the return is a 400. This is especially useful when you want to access the data programmatically. More on extending Alice below and how to get access to the return value of the requested route.

The same basic usage is applied to all the routes listed, as you can see:

Connections


# List connections
curl -i http://localhost:9999/conn
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:30:52 GMT
Content-Type: text/json
Content-Length: 287

{"conn":[{"pid":"...","ip":"127.0.0.1","port":"5672","peer_address":"127.0.0.1" ...}]}

Exchanges


# List the current exchanges
curl -i http://localhost:9999/exchanges
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:34:14 GMT
Content-Type: text/json
Content-Length: 654

{"exchanges":[{"name":"amq.rabbitmq.log","type":"topic","durable":"true","auto_delete":...}

Queues


# List the current queues
curl -i http://localhost:9999/queues   
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:35:42 GMT
Content-Type: text/json
Content-Length: 60

{"queues":[{"memory":"212988","name":"noises","vhost":"/"}]}

Bindings


# List the current bindings
curl -i http://localhost:9999/bindings
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:36:13 GMT
Content-Type: text/json
Content-Length: 69

{"bindings":[{"queue":"noises","exchange":"","from_queue":"noises"}]}

Permissions


# List permissions
curl -i http://localhost:9999/permissions
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:37:32 GMT
Content-Type: text/json
Content-Length: 42

{"permissions":{"vhosts":[{"name":"/", "users":[{"name":"guest","configure":".*","read":".*","write":".*"}]}]}}

# You can list permissions for a user
curl -i http://localhost:9999/permissions/amr
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:50:33 GMT
Content-Type: text/json
Content-Length: 42

{"permissions":{"name":"guest","vhosts":[{"name":"/","configure":".*","write":".*","read":".*"}]}}

# You can list permissions on a vhost too
curl -i http://localhost:9999/permissions/vhost/root
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:50:33 GMT
Content-Type: text/json
Content-Length: 42

{"permissions":{"name":"/","users":[{"name":"guest","configure":".*","write":".*","read":".*"}]}}

# Setting permissions
curl -i -XPOST -d '{"vhost":"/", "configure":".*", "read":".*", "write":".*"}' \
  http://localhost:9999/permissions/guest
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:55:33 GMT
Content-Type: text/json
Content-Length: 38

{"permissions":{"name":"guest","vhosts":[{"name":"/","configure":".*","write":".*","read":".*"}]}}

# Deleting permissions
curl -i -XDELETE -d '{"vhost":"/"}' http://localhost:9999/permissions/guest
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:55:33 GMT
Content-Type: text/json
Content-Length: 38

{"permissions":{"name":"guest","vhosts":[]}}

Vhosts


# List vhosts
curl -i http://localhost:9999/vhosts
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:57:10 GMT
Content-Type: text/json
Content-Length: 16

{"vhosts":["/"]}

# Viewing a specific vhost
curl -i http://localhost:9999/vhosts/barneys%20list
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:59:29 GMT
Content-Type: text/json
Content-Length: 25

{"vhosts":"barneys list"}

# If it doesn't exist:
curl -i http://localhost:9999/vhosts/barneys%20listings
HTTP/1.1 400 Bad Request
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:59:59 GMT
Content-Type: text/json
Content-Length: 34

{"barneys listings":"not a vhost"}

# Add a vhost
curl -i http://localhost:9999/vhosts -XPOST -d'{"name":"barneys list"}'
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 07:58:09 GMT
Content-Type: text/json
Content-Length: 31

{"vhosts":["/","barneys list"]}

# Delete a vhost
curl -XDELETE -i http://localhost:9999/vhosts/barneys%20list
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:02:44 GMT
Content-Type: text/json
Content-Length: 16

{"vhosts":["/"]}

Now, there is a module in the Alice called control. There are a lot of routes and a lot of functionality built-in here, so let's dig in.

Control


# Getting the status of the server
curl -i http://localhost:9999/control 
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:05:19 GMT
Content-Type: text/json
Content-Length: 151

{"status":[{"applications":["rabbit","mnesia","os_mon","sasl","stdlib","kernel"], \
"nodes":["rabbit@YPCMC05591"],"running_nodes":["rabbit@YPCMC05591"]}]}

# Stopping the rabbitmq-server
curl -XPOST -i http://localhost:9999/control/stop  
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:06:02 GMT
Content-Type: text/json
Content-Length: 20

{"status":"stopped"}

# Starting the rabbitmq-server application
curl -XPOST -i http://localhost:9999/control/start_app
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:06:50 GMT
Content-Type: text/json
Content-Length: 20

{"status":"started"}

# Stopping the rabbitmq-server application
curl -XDELETE -i http://localhost:9999/control/stop_app
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:15:56 GMT
Content-Type: text/json
Content-Length: 20

{"status":"stopped"}

# Reset the rabbitmq-server application
curl -XPOST -i http://localhost:9999/control/reset    
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:07:15 GMT
Content-Type: text/json
Content-Length: 18

{"status":"reset"}

# Or force-resetting the server
curl -XPOST -i http://localhost:9999/control/force_reset
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:07:27 GMT
Content-Type: text/json
Content-Length: 18

{"status":"reset"}

# Clustering a set of nodes
curl -XPOST -i http://localhost:9999/control/cluster -d'{"nodes":["bob@otherhost"]}'
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:14:10 GMT
Content-Type: text/json
Content-Length: 20

{"status":"cluster"}

# Rotating rabbit logs
curl -XPOST -i http://localhost:9999/control/rotate_logs -d'{"prefix":"mn_"}'
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:15:12 GMT
Content-Type: text/json
Content-Length: 25

{"status":"rotated_logs"}

Extending

Alice is written with the intention of being highly extensible and makes it easy to do so. The controllers respond only to the four verbs with pattern-matching on the routes.

For instance, a very basic controller looks like this:


-module (say).
-export ([get/1, post/2, put/2, delete/2]).

get([]) -> {"hello", <<"world">>};
get(_Path) -> {"error", <<"unhandled">>}.

post(_Path, _Data) -> {"error", <<"unhandled">>}.
put(_Path, _Data) -> {"error", <<"unhandled">>}.
delete(_Path, _Data) -> {"error", <<"unhandled">>}.

There are the 4 RESTful verbs that the controller responds. Now, if you were to compile this in Alice (in src/rest_server/controllers), then the route http://localhost:9999/say would now be accessible. Cool!


curl -i http://localhost:9999/say
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:20:57 GMT
Content-Type: text/json
Content-Length: 17

{"hello":"world"}

Now let's add a route to say hello to someone:


-module (say).
-export ([get/1, post/2, put/2, delete/2]).

get([Name]) -> {"hello", erlang:list_to_binary(Name)};
get([]) -> {"hello", <<"world">>};
% ....

curl -i http://localhost:9999/say/ari
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:21:54 GMT
Content-Type: text/json
Content-Length: 15

{"hello":"ari"}

Finally, with every other verb than get, we are given data to extract. Let's see how to pull some data in a post. The data is given as a proplist with binary keys, we it's pretty easy to pull them out:


% ...
post([], Data) ->
  Name = erlang:binary_to_list(proplists:get_value(<<"name">>, Data)),
  {"hello back", erlang:list_to_binary(Name)};
post([]) -> 
% ...

Let's check it:


curl -i http://localhost:9999/say -XPOST -d'{"name":"ari"}'
HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Tue, 04 Aug 2009 08:23:54 GMT
Content-Type: text/json
Content-Length: 20

{"hello back":"ari"}

It's as easy as pie to extend Alice.

Wonderland

Wonderland is the webUI to Alice. It is driven by the javascript framework Sammy and Alice in the backend. Because the framework is client-side and accesses the data through ajax, Wonderland can be deployed nearly anywhere.

Quickstart


cd alice
make wonderland

Community

Or feel free to ping me on email (arilerner dot mac dot com) if you have any questions.

alice's People

Contributors

amr avatar auser avatar cooldaemon avatar jashmenn avatar solidsnack avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

alice's Issues

FreeBSD ./start.sh fails

I am using a FreeBSD 7.3 OS.

After retrieving alice I run a ./start.sh and get the following :

(cd ebin; erl -pa -pa ebin -noshell -run make_boot write_scripts alice)
{"init terminating in do_boot",{undef,[{make_boot,write_scripts,[["alice"]]},{init,start_it,1},{init,start_em,1}]}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
*** Error code 1

Stop in /home/daryl/public_html/alice.
{"init terminating in do_boot",{'cannot get bootfile','alice.boot'}}

Crash dump was written to: erl_crash.dump

init terminating in do_boot ()

If I then just run the 'make boot' command I still get the error:
(cd ebin; erl -pa -pa ebin -noshell -run make_boot write_scripts alice)
{"init terminating in do_boot",{undef,[{make_boot,write_scripts,[["alice"]]},{init,start_it,1},{init,start_em,1}]}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
*** Error code 1

rabbitmq is running and operational so I am unsure as to what the problem is??

Alice logrotate

Alice integration with the logrotate command would be useful, during installation. The 1.6.0 release of RabbitMQ, provides a pre-built installed /etc/logrotate.d script. RabbitMQ also provides a logrotate command:

rabbitmqctl -n [email protected] log_rotate [spec]

Something similar for Alice would be quite useful. Also, the logrotate dateext and gzip compress options would be nice too.

Unable to view permissions

I am exploring rabbitmq and alice/wonderland, everything works great except for accessing permissions from alice/wonderland. When I try the permissions link in wonderland or via rest in alice it fails. Here is the report from it. Unfortunately know too little about erlang to have a clue.

=CRASH REPORT==== 6-Oct-2009::14:14:30 ===
crasher:
pid: <0.80.0>
registered_name: []
exception error: no function clause matching
lists:map(#Fun<permissions.1.43242716>,
{badrpc,
{'EXIT',
{undef,
[{rabbit_access_control,list_vhost_users,
[<<"/">>]},
{rpc,'-handle_call/3-fun-0-',5}]}}})
in function permissions:'-get/1-fun-1-'/1
in call from lists:map/2
in call from permissions:get/1
in call from rest_server:handle/2
in call from mochiweb_http:headers/5
initial call: mochiweb_socket_server:acceptor_loop/1
ancestors: [mochiweb_http,rest_server,rest_server_sup,<0.56.0>,<0.55.0>]
messages: []
links: [<0.67.0>,#Port<0.863>]
dictionary: [{mochiweb_request_path,"/permissions"}]
trap_exit: false
status: running
heap_size: 6765
stack_size: 23
reductions: 2139
neighbours:

/permissions crashes with rabbitmq v. 1.7.0

I'm getting this error with v. 1.7.0 using the default configuration. Which gives guest read/write permissions:

curl -i http://localhost:9999/permissions/
curl: (52) Empty reply from server

In the erlang console:
Error: {json_encode,{bad_term,{<<"guest">>,<<".">>,<<".">>,<<".*">>}}}

=CRASH REPORT==== 27-Jan-2010::22:16:44 ===
crasher:
pid: <0.83.0>
registered_name: []
exception error: bad argument
in function iolist_size/1
called as iolist_size({permissions,
{struct,
[{vhosts,
[{struct,
[{"name",<<"/">>},
{"users",
[{struct,
[{"name",
{<<"guest">>,<<".">>,<<".">>,
<<".">>}},
{"configure",<<".
">>},
{"write",<<".">>},
{"read",<<".
">>}]}]}]}]}]}})
in call from mochiweb_request:respond/2
in call from mochiweb_http:headers/5
initial call: mochiweb_socket_server:acceptor_loop/1
ancestors: [mochiweb_http,rest_server,rest_server_sup,<0.57.0>,<0.56.0>]
messages: []
links: [<0.68.0>,#Port<0.832>]
dictionary: []
trap_exit: false
status: running
heap_size: 610
stack_size: 23
reductions: 906
neighbours:

=ERROR REPORT==== 27-Jan-2010::22:16:44 ===
{mochiweb_socket_server,235,{child_error,badarg}}

However, running:
curl -i http://localhost:9999/permissions/vhost/root works ok.

Can't connect to rabbit node?

Running ./start.sh I get the following:

=PROGRESS REPORT==== 19-Nov-2009::11:11:41 ===
    application: alice
    started_at: '[email protected]'
Eshell V5.6.3  (abort with ^G)

=ERROR REPORT==== 19-Nov-2009::11:10:18 ===
Lost connection with rabbitmq_server. Trying to regain connection to '[email protected]'

=ERROR REPORT==== 19-Nov-2009::11:10:23 ===
Error in process <0.113.0> on node '[email protected]' with exit value:   
{badarg,[{erlang,list_to_existing_atom,["rabbit@h8"]},{dist_util,recv_challenge,1},
{dist_util,handshake_we_started,1}]}

Any idea what this could be? rabbit@h8 is definitely running, alive and well.

Using RabbitMQ 1.7.0

Error durring make boot

After not finding the bootfile:

$ ./start.sh
(cd ebin; erl -pa ebin -noshell -run make_boot write_scripts alice)
{"init terminating in do_boot",{undef,[{make_boot,write_scripts,[["alice"]]},{init,start_it,1},{init,start_em,1}]}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
make: *** [boot] Error 1
{"init terminating in do_boot",{'cannot get bootfile','alice.boot'}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()

I tried creating it as suggested in the Common Problems but ran into:

$ make boot
(cd ebin; erl -pa ebin -noshell -run make_boot write_scripts alice)
{"init terminating in do_boot",{undef,[{make_boot,write_scripts,[["alice"]]},{init,start_it,1},{init,start_em,1}]}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
make: *** [boot] Error 1

Any hints whats going wrong?

/users/nonexisting and /vhosts/nonexisting crashes

$ curl -i "http://localhost:9999/users/nonexisting" returns: "curl: (52) Empty reply from server"

And the following error in Alice shell:

(alice@pipeline)1> Error: {function_clause,
[{mochijson2,'-json_encode_proplist/2-fun-0-',
[{ok,400,[],{"nonexisting",<<"not a user">>}},
"{",
{encoder,null,false}]},
{lists,foldl,3},
{mochijson2,json_encode_proplist,2},
{rest_server,jsonify,1},
{rest_server,run_controller,4},
{mochiweb_http,headers,5},
{proc_lib,init_p_do_apply,3}]}

=CRASH REPORT==== 3-May-2010::00:51:02 ===
crasher:
initial call: mochiweb_socket_server:acceptor_loop/1
pid: <0.147.0>
registered_name: []
exception error: bad argument
in function iolist_size/1
called as iolist_size({ok,400,[],{"nonexisting",<<"not a user">>}})
in call from mochiweb_request:respond/2
in call from mochiweb_http:headers/5
ancestors: [mochiweb_http,rest_server,rest_server_sup,<0.59.0>,<0.58.0>]
messages: []
links: [<0.70.0>,#Port<0.892>]
dictionary: []
trap_exit: false
status: running
heap_size: 987
stack_size: 24
reductions: 888
neighbours:

=ERROR REPORT==== 3-May-2010::00:51:02 ===
{mochiweb_socket_server,235,{child_error,badarg}}

An identical behavior can be seen with /vhosts/nonexisting

Adding user hangs alice

Alice hangs when I try adding a user with:
curl -i -XPOST -d'{"username":"n8gray", "password":"blah"}' http://locahost:9999/users

The "ebeam.smp" process starts taking 40% of my cpu and doesn't stop until I abort the alice process. Nothing interesting comes up in the rabbitmq logs

I'm using OS X 10.5.7 on an Intel mac. Some more version strings:
Erlang R13B01 (erts-5.7.2) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false]
RabbitMQ 1.6.0 (AMQP 8-0)
git head of alice (8aa4f43)

Thanks,
-n8

User UI feedback

On the Wonderland Users UI, we noticed the default behavior to delete a user, when the user is clicked, is a risky. It will be too easy for a person, to accidentally click "OK". What is probably better is if the click opens a window, with two options. One option is to change the user's password, the other option is to delete the user. Changing a user's password is probably a likely Admin task.

Same feedback applies to the VHost UI.

unable to view bindings

the bindings view is blank, despite the /bindings/vhost call working on the rest interface.

Read-only mode for Wonderland

Management has made a request to configure a read-only mode for the Wonderland GUI web interface.

We use the RESTful interface to make updates for our deployment scripts. Likewise Wonderland is very useful to look at the state of VHosts and queues.

But, since there is no authentication, people are concerned that either a malicious or even a casual browser might not understand that 'delete' user x or 'delete' vhost y is not a good idea. Although the action is logged it could still cause a lot of havoc, especially since the configuration is not backed up.

Therefore, it would be useful to be able to start Wonderland in a read-only mode. In this mode, updates such as delete, would not be allowed.

Unable to list queues

Trying to list queues via wonderland, I get such an error in alice:

=INFO REPORT==== 7-Sep-2010::14:52:32 ===

(rest_server:232) Error in rest server: {function_clause,

                                     [{lists,map,
                                       [#Fun<queues.0.39488572>,
                                        {badrpc,
                                         {'EXIT',
                                          {undef,
                                           [{rabbit_amqqueue,info_all,
                                             [<<"/">>,
                                              [name,durable,auto_delete,
                                               arguments,messages_ready,
                                               messages_unacknowledged,
                                               messages_uncommitted,
                                               messages,acks_uncommitted,
                                               consumers,transactions,
                                               memory]]},
                                            {rpc,local_call,3},
                                            {queues,get_info_for,2},
                                            {queues,get_impl,1},
                                            {rest_server,run_controller,4},
                                            {mochiweb_http,headers,5},
                                            {proc_lib,init_p_do_apply,
                                             3}]}}}]},
                                      {queues,get_impl,1},
                                      {rest_server,run_controller,4},
                                      {mochiweb_http,headers,5},
                                      {proc_lib,init_p_do_apply,3}]}

$ /usr/sbin/rabbitmqctl list_vhosts
Listing vhosts ...

/

celery_test

...done.

What am I doing wrong? How can it be fixed? Give me a note if you need more information.

Scalable UI

The UI visually looks pretty cool. But I think the Wonderland Dashboard could be designed to be more scalable. What happens when there are ten, twenty or even hundreds of queues, vhosts or exchanges.

I think it would be better to have an initial global or sum total perspective. I also liked the original dashboard information, which contained the "running nodes". So, I think it would be better if initially the user saw a globals dashboard, showing the cluster running nodes, the total memory used, total number of queues, total number of Vhosts, etc.

But, make each item such as queues or vhosts clickable. When the user clicks on Vhosts they would then see a list of Vhosts, with total memory and total messages for each. Each of the individual Vhosts would also be clickable.

The second click, opens the Vhost and shows a list of queues, with name, memory, messages, consumers, unacknowledged.

This could be implemented internally by having the following APIs:

curl -i http://localhost:9999/dashboard/dashboard
curl -i http://localhost:9999/dashboard/dashboard/vhost/LOLcats
curl -i http://localhost:9999/dashboard/dashboard/vhost/LOLcats/cats_queue

What do you think?

Small issue with 'make wonderland'

This is a small issue but may affect some users.

In the event that a user does not have git installed on the system, typing 'make wonderland' will return an error:

[root@q1 auser-alice-8a1a9ffdfe19b95116f9ff9eb0c32a0ea2621b43]# make wonderland
[ -d web//wonderland ] || (mkdir web/ && cd web/ && git clone git://github.com/auser/wonderland.git)
/bin/sh: git: command not found

However, it will go ahead and create web/. This is a problem because the next time 'make wonderland' is run, it will error because web/ already exists:

[root@q1 auser-alice-8a1a9ffdfe19b95116f9ff9eb0c32a0ea2621b43]# make wonderland
[ -d web//wonderland ] || (mkdir web/ && cd web/ && git clone git://github.com/auser/wonderland.git)
mkdir: cannot create directory `web/': File exists
make: *** [wonderland] Error 1

make wonderland doesn't work

Running "make wonderland" attempts to pull from the private wonderland repo, not the public one. I'd love to submit a patch here (it's an easy fix), but I'm not really sure how. Also, I don't feel like forking and issuing a pull request for something so simple :-)

Alice stop script

Assuming we have multiple Alice instances, running on different ports. We require a method to stop a unique instance. This is for usage with the init.d scripts. Something similar to the rabbitmqctl commands would be nice.

For example:

alice.sh stop -n [email protected]

This would allow combining the Alice admin stop command with the corresponding RabbitMQ stop command:

rabbitmqctl stop_app -n [email protected]
alice.sh stop -n [email protected]

Document your build environment

It would be great if you could add in the Readme or on the wiki some docs about the environment setup to correctly compile the application.

Starting from a standard install of ubuntu it seems that it only compiles mochiweb but not anything related to alice

Here's the output, it seems is not picking up anything to compile in directory others than deps.
Feels like it's not finding make_boot but I'm new to erlang and I can't work out how to fix it.

make[1]: Entering directory `/home/blank/personal/alice/deps/mochiweb'
(cd src;make all)
make[2]: Entering directory `/home/blank/personal/alice/deps/mochiweb/src'
erlc -W -I ../include  +debug_info -o ../ebin mochifmt.erl
erlc -W -I ../include  +debug_info -o ../ebin mochifmt_records.erl
erlc -W -I ../include  +debug_info -o ../ebin mochifmt_std.erl
erlc -W -I ../include  +debug_info -o ../ebin mochihex.erl
erlc -W -I ../include  +debug_info -o ../ebin mochijson2.erl
erlc -W -I ../include  +debug_info -o ../ebin mochijson.erl
erlc -W -I ../include  +debug_info -o ../ebin mochinum.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_app.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_charref.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_cookies.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_echo.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_headers.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_html.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_http.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_multipart.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_request.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_response.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_skel.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_socket_server.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_sup.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_util.erl
erlc -W -I ../include  +debug_info -o ../ebin reloader.erl
make[2]: Leaving directory `/home/blank/personal/alice/deps/mochiweb/src'
make[1]: Leaving directory `/home/blank/personal/alice/deps/mochiweb'
(cd ebin; erl -pa ebin -noshell -run make_boot write_scripts rest_app)
{"init terminating in do_boot",{undef,[{make_boot,write_scripts,[["rest_app"]]},{init,start_it,1},{init,start_em,1}]}}

Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
make: *** [make_boot] Error 1

Make problems

'make' produces several warnings:

[root@q1 auser-alice-581132a670c48be183fc34eec7e6ec6e44b7ac2c]# make

make[1]: Entering directory `/root/auser-alice-
581132a/deps/mochiweb'
(cd src;make all)

make[2]: Entering directory `/root/auser-alice-581132a670c48be183fc34eec7e6ec6e44b7ac2c/deps/mochiweb/src'

make[2]: Nothing to be done for `all'.

make[2]: Leaving directory `/root/auser-alice-581132a670c48be183fc34eec7e6ec6e44b7ac2c/deps/mochiweb/src'

make[1]: Leaving directory `/root/auser-alice-581132a670c48be183fc34eec7e6ec6e44b7ac2c/deps/mochiweb'
(cd ebin; erl -pa ebin -noshell -run make_boot write_scripts rest_app)
write_scripts for "rest_app"

Writing to "rest_app.rel" (as rest_app)

WARNING rest_app: Source code not found: alice_log.erl

WARNING rest_app: Source code not found: rest_app.erl

WARNING rest_app: Source code not found: rest_server.erl

non-root vhost exchanges and queues not showing via REST

In a test scenario with a fanout exchange and a single consumer queue, if I use the root vhost, I can hit the REST interface's /exchanges, /queues, and /bindings and get reasonable-looking results from each. If I create a vhost named "test" and use that, /bindings/test works ok:
curl -i http://172.16.200.99:9999/bindings/test
...
{"bindings":[{"queue":"consumer_recv","exchange":"","from_queue":"consumer_recv"},{"queue":"consumer_recv","exchange":"testroom","from_queue":"none"}]}

But /exchanges/test doesn't work at all:
curl -i http://172.16.200.99:9999/exchanges/test
...
{"error":"unhandled"}

And /queues/test produces this:
curl -i http://172.16.200.99:9999/queues/test
...
{"queues":[{}]}

Is the REST API supposed to give full access to bindings, queues, and exchanges in non-root vhosts? Is suffixing the vhost name the correct way to access them?

Integration with /etc/init.d

Need scripts to start, stop, reload and status Alice. Also scripts to assist with logrotate, via logrotate.d.

A RabbitMQ installation provides such scripts for RabbitMQ, so providing similar scripts for Alice would assist with integration.

Reconnecting moves PMs all the way to the left.

I had some PMs open talking to people, then I closed the window and returned later and all my PMs were moved to the leftmost tabs. I would think that leaving the layout just how I left it would be the desired behavior.

I don't know if this is by design or not, so maybe it's a good thing to have them all move to the left to force me to clean them out when I reconnect, heh.

Alice health monitoring

Request to add a new section, under Dashboard, to manage Nodes. Overall we need a good mechanism to handle Node maintenance, without involving AppSupport. This can also help with integration with load balancers, such as F5.

The features requested:

(1) Health OK / Not OK

This should be automatic, but it should be settable via manual override, via a UI checkbox. If a Node is OK, health is OK, if the Node is down health is 404.

Health is provided via the following example URL: http://np143.wc1.yellowpages.com:5671/health

The purpose is to notifiy external load-balancers, such as F5, that traffic should not be routed to this node. F5 can be configured to check both a URL and a TCP port to determine if a monitored service is available.

So, an admin user might set this to "Not OK" in order to bring the node down for maintenance in a graceful manner. Existing AMQP clients would continue to stay connected until they complete their task. But the F5 would not direct new clients to connect to this node.

Always though, if the AMQP service dies, then Alice should detect this condition and also set the Health to Not OK.

(2) Node Up / Down

This should trigger the rabbitmqctl stop_app and start_app methods. These manually start and stop the AMQP service itself on port 5672. Erlang continues to run. Also, if an AMQP port is down, the health check should automatically get set to "Not OK"

(3) Node traversal

The UI should provide html links, which make it easy to traverse from Node to Node.

Queues resource not returning a value

I have Alice and Wonderland both up and running, and I am noticing
that all of the REST resources are working great with the exception of
the queues resource.

Using curl:

root@sfqload01 /var/lib/rabbitmq

$ curl -i http://localhost:9999/queues

HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Wed, 17 Feb 2010 08:04:58 GMT
Content-Type: text/json
Content-Length: 13
{"queues":[]}

root@sfqload01 /var/lib/rabbitmq

So Wonderland obviously shows an empty page. But when i query
rabbitmqctl directly I can see the output that I would like to see via

Alice:

root@sfqload01 /var/lib/rabbitmq
$ rabbitmqctl list_queues -p /nanite memory name messages_unacknowledged messages
Listing queues ...
6056 mapper-15e44eb68b0841a9098bac4fbad56a2d 0 0
9432 registration 0 0
6056 mapper-46f4166745cf57fe1b6e8d55885614ec 0 0
2915112 nanite-b 5 1476
1802424 nanite-a 6 1368
9432 request 0 0
9432 mapper-offline 0 0
19192 heartbeat 0 0
...done.
root@sfqload01 /var/lib/rabbitmq

Alice start script

The init.d scripts require a standard method to start Alice. Since multiple RabbitMQ brokers can be started on different ports, we also need to be able to start multiple Alice instances on different ports.

For example:

alice.sh start -n [email protected] -port 9001 -log /var/log/alice
alice.sh start -n [email protected] -port 9002 -log /var/log/alice

Log files should not overlap, similar to the RabbitMQ logs

Alice multiple logs

Currently the alice log is named "alice.log". This creates a problem, when or if, multiple Alice instances are running. Ideally Alice will name its log files similar to RabbitMQ.

For example:

alice@[email protected]

Cannot find alice.boot

I also got the message from start.sh about not being able to find alice.boot, which was mentioned in a comment on another ticket.
Can anyone explain in more detail how this can be fixed, as I have no Erlang knowledge?

Error in rest server when getting connections

Hi,

I'm getting an error when trying to get connections. Other alice requests work.

curl -i http://localhost:9999/conn
HTTP/1.1 404 Object Not Found
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Date: Thu, 24 Feb 2011 15:59:41 GMT
Content-Type: text/plain
Content-Length: 10

Not found.

with Alice showing

=INFO REPORT==== 24-Feb-2011::15:59:41 ===
(rest_server:232) Error in rest server: {{case_clause,
                                          {client_properties,
                                           [{<<"information">>,longstr,
                                             <<"http://github.com/tmm1/amqp">>},
                                            {<<"product">>,longstr,<<"AMQP">>},
                                            {<<"platform">>,longstr,
                                             <<"Ruby/EventMachine">>},
                                            {<<"version">>,longstr,
                                             <<"0.6.7">>}]}},
                                         [{conn,convert_prop_for_json,1},
                                          {lists,map,2},
                                          {lists,map,2},
                                          {conn,'-get/1-fun-0-',1},
                                          {lists,map,2},
                                          {conn,get,1},
                                          {rest_server,run_controller,4},
                                          {mochiweb_http,headers,5}]}

I'm connecting to rabbitmq using the Ruby amqp gem.

rabbitmqct list_connections shows what's connected

rabbitmqctl list_connections
Listing connections ...
guest   127.0.0.1   44237   running
guest   127.0.0.1   50008   running

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.