deploying additional storage nodes

John Sanda jsanda at redhat.com
Fri Jul 19 01:37:29 UTC 2013


On Jul 18, 2013, at 6:50 PM, Larry O'Leary <loleary at redhat.com> wrote:

> On Thu, 2013-07-18 at 15:55 -0400, Stefan Negrea wrote:
>> 
>> ----- Original Message -----
>>> From: "Heiko W.Rupp" <hrupp at redhat.com>
>>> To: rhq-devel at lists.fedorahosted.org
>>> Sent: Thursday, July 18, 2013 2:28:04 PM
>>> Subject: Re: deploying additional storage nodes
>>> 
>>> 
>>> Am 18.07.2013 um 20:46 schrieb Stefan Negrea:
>>>> However, the one thing that I did not yet see mentioned for option 3 is the
>>>> initial install.
>>> 
>>> Initial install on the server side is as today.
>>> On the other nodes, when we have the agent there, we can eat the dog food and
>>> sent a bundle
>>> down that happens to contain C*
>> 
>> Our initial implementation and design had the concept of bundles and installing storage nodes via agents. However, that option was discarded in favour of the rhqctl approach. The primary reason for dropping that approach was the disparity between installing different parts of essential infrastructure. Server via command line installer, agent via jar installer, and then storage node via bundles. Way too complicated for casual users to setup and expand a system...
> 
> Perhaps this has been made too complicated. From early discussions the
> plan was that the installer would take care of the initial storage node.
> How it does that isn't important, only that it happens. 
> 
> If I want to add an additional storage node then I need to install an
> additional RHQ server in an HA manner. Again, the storage node would be
> a byproduct of this process. 
> 
> Finally, an option would be provided to add a storage node without an
> additional RHQ server. In this manner, the expectation would be that I
> install an agent and point it at the server and then use the storage
> node plug-in to spin up a new storage node. For that matter, I should be
> able to spin up a new storage node on every machine -- if I choose -- as
> long as there is an agent running.
> 
> From this thread, it seems that somehow this entire process has become
> too complex. It also sounds like from a security point of view, someone
> can install a storage node without an administrator (user with the
> appropriate permissions) confirming/validating it? 
> 
> As for using bundles, not even sure they would be needed. It seems like
> the storage node plug-in itself should have the understanding of
> installing and configuring the storage node regardless of this being the
> first, second, fiftieth. As a user with the correct permissions I would
> simply click the "Create New Storage Node" operation on the storage node
> admin page and be asked which agent I wanted it on. 
> 
> Overall option 3 seems like the only choice but there are still some
> wrinkles. I think these wrinkles may be due to the complexity of how we
> are actually installing and configuring Cassandra in the first place.
> Don't get me wrong, I am sure there are reasons for this implementation
> choice but in order to come to a resolution that works and keeps things
> as simple and basic as possible, the implementation may need to be
> modified.
> -- 
> Larry O'Leary
> https://plus.google.com/u/0/112645929986009801513

I noticed that one of my previous emails had some typos which might have caused some confusion; so, I want to clarify to make a point perfectly clear. We neither want nor expect JON users/admins to be Cassandra admins. I will take that a step further though. We want to be able to black box Cassandra in such a way the JON users do not even have to know that Cassandra is running. They just know that RHQ/JON has this additional component called a Storage Node.

With respect to the concerns around complexity in this thread, I think some things got lost in the details. We *are* moving in a direction of less and not more complexity. Prior to starting this discussion, I thought that the storage installer would need to be updated to either directly query the database or make a call to the server over the remote APIs (the same ones used by the CLI). And both of those changes would entail some user-facing to the installer, albeit minor ones.

But now the work I had already started planning for one of the aforementioned approaches, simply isn't needed. Any storage installer changes will be minor and implementation only. And the details I have described for option 3, are all things that are either already implemented or are already in the pipeline to be done for RHQ 4.9.

Unless the user wants/needs to use non-defaults port for the initial storage node, he can simply run rhqctl install. Nothing else needed. And if the user wants to install an additional storage nodes, all he will need to do is run rhqctl install --storage. This is assuming he only wants to install another storage node. You are not required to install an additional RHQ Server as well. If he wants to install both a storage node and a server, then he can just run rhqctl install (without any options). The server and agent(s) will take care of everything else.

In terms of how we install and configure Cassandra, believe me when I say it is nothing fancy :) What we do for production is the same thing we do for automated tests that run every day and for the dev-container. We unzip Cassandra and update a couple config files. That's it.

- John


More information about the rhq-devel mailing list