On 03/08/2014 09:35 AM, Coeuz wrote:
The idea is the following one:
From the documentation it can be deduced that currently a new
project/cluster can be created either by hand, configuring all the
components manually, or using the quickstart command.
However, when creating something a little more customized than the
quickstart cluster nothing prevents the user to having to manually tweak
things in orther to build the cluster as desired.
So, I thought that it would be interesting (and quite easy to implement)
to add some options to the quickstart command in order to indicate some
basic things such as the cluster name, the number of servers, binding
Pushing it a little further, it would be interesting to also be able to
indicate component IP addresses and let zato “ssh” into the
corresponding machines in order to create the components there
(something similar to what Glassfish server does when creating new nodes
from the Admin Server), however, I think that this might require a
little more tweaking and might be beyond the scope of a simple
What do you think about it?
And if you find this interesting, how should I proceed to push a patch
(or just a candidate) into the repositories?
your ideas sound very interesting indeed!
Quickstart is simply a wrapper around existing CLI commands.
For instance, there’s a ‘create server’ command which expects a couple
of arguments that are processed and the result is a server.
These arguments are read from command line but quickstart passes them on
directly to each of the CLI commands’ Python classes.
Still using ‘create server’ as an example, let’s check its .execute
method over here
Basically, it connects to ODB, inserts information on a newly created
server into the database and sets up all the filesystem directories and
Now quickstart here
invokes the very same .execute method providing it with arguments it
So to answer your question on how to go about extending quickstart - the
first thing is to extend the underlying individual commands with options
needed and then it’s only a matter of making use of them in quickstart.
GH-wise, if you’d like to work on it, let’s create a ticket here
Then fork the repository and create a feature branch in the format of
Where nickname is your GH handle and 123456 is the ticket number.
Also, please prefix all the commits with “GH #123456” - git doesn’t keep
track of what feature branch a given commit comes from so this is how it
can be done, i.e. this at least lets one quickly find the corresponding
As for the Glassfish idea - I haven’t used Glassfish but the idea is
certainly interesting and one that we should have. I’d very much like to
have a central place to dispatch new servers from over ssh but an aspect
that can’t be overlooked in that case is the GUI.
This must be snappy and drag’n’drop with new nodes being added via
pulling strings between a central config server (a concept we don’t have
right now) and the new nodes about to be added to an environment.
This would also dovetail nicely with my plans to pretty up the
load-balancer’s GUI - this would be a great place to use a sort of
dragging icons onto canvas.
By the way, can you please send a couple of links to the Glassfish
feature you’re thinking of? Would be great to check it out.