classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view


At my company we're considering using glu as a deployment tool in part of our continuous deployment chain.
So naturally the questions that we ask are the meta:
1. What's the roadmap?
2. Who's using it except linkedin?
3. If linkedin is doing continuous deployment then can we learn more from how glu is being used to implement that?
4. How open glu is for external contributions?

I realize it's an open source project and a labor of love, myself I'm an owner of such an open source project so I appreciate the great work put into the product and I hope you understand my curiosity, thanks :)
Reply | Threaded
Open this post in threaded view

Re: Roadmap

Hello Ran

Glad to hear you are considering glu :)

In regards to your questions:

1) the short term roadmap is the following (in no particular priority order):
* handle parent/child relationship properly (so that you can deploy a container (parent) and independently a webapp in it (child)). There is already support for this in the agent but the console does not handle it properly.
* handle dependency between entries (ex: service1 needs to be deployed before service2)
* add tagging capabilities (ability to 'tag' any entry in the system model so that you can query by tag, similar to label in gmail) which is very powerful when combined with the cli
* release packages / pre-built artifacts: this is almost done (it is kind of obvious so that you don't have to rely on gradle and whatnot in order to use glu)
* add cli for the console
* add dsl to allow any kind of plan deployment
* add glu scripts for 'standard' deployments (ex: jetty + war, memcache, etc...) and also as example of glu scripts
* ...

2) the project was open source about 1 month ago and as far as I know it is not being used outside LinkedIn (yet :))

3) The key concept in glu is the concept of system model (aka 'desired state'). At LinkedIn the system model is actually generated from a set of xml files (which is internally called the 'Model'). The critical idea is that this set of xml files is checked in (in subversion) and gets updated when new release builds are produced or when new machines need to be added/removed. Once this is done, the system model is generated and loaded in the console, thus effectively loading the new 'desired state'. glu can then compute the delta and then applications get updated (this process cannot be fully automated due to the fact that glu does not handle (yet) the concepts of dependency). Since the Model is in svn, it is easy to keep track of changes and 'rollback' to previous versions of the system. The console can be wiped out, it is not a big deal: the Model can simply be reloaded in the console.

4) I am very open to external contributions especially if we can make glu evolve along a common path :)