(Migrated) Add options for the quickstart command

(This message has been automatically imported from the retired mailing list)

Hello,

I am pretty new to the zato “beast” and at the moment I have to admit
that I only followed the quickstart tutorial and played a bit with some
other configurations.

However I quickly found a feature which I believe would be interesting
but which I think is currently missing (I might be wrong in this point,
so please correct me in that case), so I would like to expose my idea
here and if it is considered a good one, ask for some indications about
how to contribute to it.

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
addresses, etc.

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
"quickstart" command.

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?

Regards,
Coeuz

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
addresses, etc.

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
“quickstart” command.

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?

Hi Coeuz,

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

https://github.com/zatosource/zato/blob/master/code/zato-cli/src/zato/cli/create_server.py#L188

Basically, it connects to ODB, inserts information on a newly created
server into the database and sets up all the filesystem directories and
files.

Now quickstart here

https://github.com/zatosource/zato/blob/master/code/zato-cli/src/zato/cli/quickstart.py#L258

invokes the very same .execute method providing it with arguments it
expects.

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

nickname-f-123456-short-desc-of-the-feature

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
ticket.

https://github.com/zatosource/zato/commits/master

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
Javascript map of servers that could be again added or deleted via
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.

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
addresses, etc.

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
“quickstart” command.

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?

Hi Coeuz,

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

https://github.com/zatosource/zato/blob/master/code/zato-cli/src/zato/cli/create_server.py#L188

Basically, it connects to ODB, inserts information on a newly created
server into the database and sets up all the filesystem directories and
files.

Now quickstart here

https://github.com/zatosource/zato/blob/master/code/zato-cli/src/zato/cli/quickstart.py#L258

invokes the very same .execute method providing it with arguments it
expects.

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

nickname-f-123456-short-desc-of-the-feature

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
ticket.

https://github.com/zatosource/zato/commits/master

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
Javascript map of servers that could be again added or deleted via
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.