Re: admin functionality refactoring
The term admin functionality itself means something that only an admin
should be able to do. We had been through a discussion on admin
functionality earlier and reviewed the following options -
1. Expose admin commands as RPC and in addition to that, provide command
line tools that talk to the controller using this RPC. This way non-java
clients also have an option of executing the admin commands from code.
2. Expose admin commands as command line tools only and notify the
controller using zookeeper. The argument is that since these are "admin"
operations, there is no reason someone should be allowed to fire an API
request and change cluster wide metadata, configuration or state. Another
assumption is that since admin operations are limited, this won't create
too much zookeeper state.
The reason we picked option #1 is because it seemed reasonable for admin
operations to be available through command line tools and to disallow
random clients from being able to change cluster state.
However, it's not the end of the world, if we think our users like option
#2 now, we can think about redesigning our admin functionality. It really
depends on what most people think the meaning of admin operations is or
On Monday, February 11, 2013, S Ahmed wrote: