Right now, bricks are sort of second-class objects. They're host:path pairs
that sort of only exist within the context of the volumes where they're used,
and they don't have any other attributes. What if they did have their own
identity and attributes? Consider the following:
gluster brick create mybrick server1:/some/random/path
OK, big deal. Now it gets a bit more interesting.
gluster brick set mybrick storage-type reallyfast
Still doesn't seem all that useful, eh?
gluster brick set otherbrick storagetype reallyfast
gluster volume set placement-pattern '*.mp4:reallyfast'
This is from http://review.gluster.org/#change,4410 which is what inspired this
line of thinking. Now things get much more interesting. We can essentially
put bricks into "placement groups" and use those to give users more control
over where their files go. Some of our competitors already do this. ;)
Here's another trick.
gluster brick stop mybrick
gluster brick move mybrick server2:/another/path
gluster brick start mybrick
Pretty obvious what happened here, isn't it? The user wants to move a brick
physically from server1 to server2. This way seems very intuitive, and because
we retain the brick's identity/attributes throughout it's very easy for us to
do the right thing - in contrast to the arcane details of current
replace-brick. Being able to start/stop individual bricks in a fully
integrated way will be very handy for testing too.
We could also do top/latency on individual bricks this way some day, and all
sorts of other tricks too. It doesn't even seem like it would be all that
complicated to implement. Any thoughts?
