Using the rest api to load the desired state and then deploy all that needs to be deployed

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

Using the rest api to load the desired state and then deploy all that needs to be deployed

rantav
Suppose I could POST an update of the desired state using the rest API (it's currently broken, but will be fixed soon).
So - what's now? Now I want to tell glu to deploy all apps that the new desired state is describing.
Reading on this page https://github.com/linkedin/glu/wiki/Console there is a description of three methods which seem to do the job in some combination but I'm not sure how to actually use them or that they are the ones I should actually be using.
There is the POST /plans
There is the GET /plans
And there is the POST /plan/<planid>/execution.

... so I would imagine I'd have to first POST /plans with planAction=redeploy and then read (GET /plans) and find my plan ids and then POST /plan/id/execution for each one of them...

Is this the recommended workflow?
Is there an easier way to tell glu to "just do it?" (a-la chef or puppet, for example that you can tell them to sync up the clients). Or perhaps "redeploy sequentially where metadata.container.name='xxx'"?

Thanks!

Related post: http://glu.977617.n3.nabble.com/Using-the-rest-api-to-load-the-desired-state-tp2131511p2132084.html
Reply | Threaded
Open this post in threaded view
|

Re: Using the rest api to load the desired state and then deploy all that needs to be deployed

frenchyan
Administrator
I already started the work for the cli in a new (remote) branch: https://github.com/linkedin/glu/tree/console-cli if you wish to see how it is being done.

I am not sure why but the wiki column is truncated (seems to be a rendering bug). If you check this instead:
https://github.com/linkedin/glu/blob/master/docs/glu_console.md the last column is not truncated anymore and you can see that:

You do a

1. POST /plans
which returns 201 (if it works) and a Location header telling you which plan was created for you (no need to call GET /plans) which will end with /plan/pppp

2. POST /plan/pppp/execution
which returns 201 (and start the execution) and a Location header about the execution that was created (of the form: /plan/pppp/execution/eeee)

3. loop on HEAD /plan/pppp/execution/eeee which returns 200 and a X-LinkedIn-GLU-Completion header telling you where is the plan execution (in percentage)

I know it may look complicated but it is this way because:

a) between 1. and 2. you can actually issue a GET to view the plan *before* executing it thus allowing you to ask for confirmation if you want to
b) 3. allows you to loop and show progress while the plan is executing asynchronously (no blocking call)

Note that the (soon to be released) cli handles all this for you and for example offers a dry run mode which simply stops at 1. and does a GET to display what would happen if you were to do it. The REST api is a low level programming API that you can use if you really want to write your own custom wrapper but it is not the original intent.

In the end you issue something like this which is equivalent to 'just do it' as you mention:

./bin/glu.sh <options for user/password> -s metadata.container.name=myapp deploy|redeploy|start|stop|undeploy

Yan
PS: the cli is my next short term task
Reply | Threaded
Open this post in threaded view
|

Re: Using the rest api to load the desired state and then deploy all that needs to be deployed

rantav
With version 1.5.0 I'm now able to upload a model like this, thanks!

curl -D - -d '{"entries": [{"agent": "api18","initParameters":{"app": "BlogSettings"},"mountPoint": "/BlogSettings/i001","script": "file:/outbrain/glu/DeployWebApp.groovy"}],"fabric": "glu-dev-1"}' -H "Content-Type: text/json" http://glua:password@tush:8080/console/rest/v1/glu-dev-1/system/model