Generic Tarball Plan

[grierj]

I'd like to put in a feature request to have Glu support the deployment of generic tarballs. I see this feature working in a way that I can provide a coordinate/uri to a tarball and have a plan that simply puts the tarball in a directory, untars it, and runs some arbitrary script.

The arbitrary script would need to take 4 options, install, uninstall, start and stop. These would be run at the self-descriptive time. If glu wants to care about status then the same script should support a status command.

This would allow glu to deploy bits of compiled code that doesn't have something like a container attached to it.

[ypujante]

From what I understand, it seems that this can already be achieved by writing a 'simple' glu script:

a) in the install phase, the glu script would fetch/download the tarball from the uri provided and untar it in a directory b) then this tarball would contain a script (shell I presume ?) that could also be a parameter (relative to the root of the tar ball) (ex: myscript.sh) c) the glu script would then invoke myscript.sh install / myscript.sh start / myscript.sh stop / myscript.sh uninstall

is that what you mean ?

If that is what you want, then glu is already designed to support such a thing. It is not built-in but that is the purpose of glu scripts. Currently at LinkedIn there are 2 glu scripts, one to deploy jetty + webapps and one to deploy tomcat + webapp. The open source version has jetty + webapps. But there can be as many glu scripts as we want. We could imagine a glu script to control activemq or a glu script to control memcached or a glu script like you describe (or at least like what I understood).

glu scripts are not really meant to be built-in anyway.

First of all, is my understanding correct ? If yes then I really think it is easy to do.

[grierj]

yes, your understanding is correct. I think you hit on the correct flow. I didn't really think it should be built-in, but a plan that works with that kind of thing would be very useful to have by default.

[ypujante]

Cool. Glad we are on the same page. I will add it to my list of tasks to do (I definitely agree that it would be useful and also lower the barrier of entry since you don't need to know groovy to use it). I also had in mind that all the config variables that are available in the glu script (through shell.env ), could be made available to the shell script as environment variables with some convention:

• shell.env['glu.agent.name'] would be made available as GLU_AGENT_NAME
• shell.env['glu.agent.fabric'] would be made available as GLU_AGENT_FABRIC

you get the idea... and it would also cover any properties you have added to the zookeeper configuration thus effectively allowing you to pass any kind of fabric dependent configuration to the script

For example, the base url for a local (to the fabric) binary repo could be defined as glu.binary.repo.base.url => your script could then issue commands like:

curl $GLU_BINARY_REPO_BASE_URL/myapp.tar.gz -o $GLU_AGENT_SCRIPTROOTDIR/$GLU_MOUNTPOINT/myapp.tar.gz