Cast for run once tasks, task that require rerunning or templating

[fairwinds]

Hi. I have been following cast development for a little while and quite like the idea so interested in giving it a spin. I have been using buildout (python) for deployments but wish to get away from it. What I like about cast is the client / server paradigm and managing tasks through an api. It fits more closely to the way I am doing most everything today and I will be able to tie my management tasks into a dashboard and gets away from all the stupidity of working with something that is geared largely to python packages and sorting package dependencies. I am interested in how cast will handle platform preparation and management tasks.

The redis example you provide to acquaint folks with cast is reasonable but simple and I am seeking feedback with respect tasks that will need to be run once, or rerun as part of an update.  I tend to deploy by starting with a base template for the server and running automation that prepares the platform (by building, installing or configuring software, installing and configuring the app(s), installing and configuring monitoring software and plugins, then performing hardening tasks. Buildout is recipe based so it is quite good in the way that you determine recipes to use to handle some piece of the deployment (ie running cmmi (config, make, make install), pulling code from a repo and doing something with it, creating files/folders, creating config files from templates). Obviously some deployments can be very simple where others can involve a more series of tasks to fully set up the server. I would like to understand how cast will handle these issues. 

[fairwinds]

Anyone?

[russell_h]

Sorry, this sort of slipped under my radar. Let me know if I'm misunderstanding you, but I think I can address this as two separate issues:

1. Server buildout, configuration and management - we're relatively content to leave this to existing configuration management systems.
   
2. "Application level" tasks. This is more what we're interested in handling. As of version 0.1 we provide a hooks system (execute scripts at various times during an application's lifecycle) [1], a template system (generate files from templates and various system info) [2] and a "data files" system [3] which allows you to keep specified files between application versions. For our next release we are also working on a plugin system that will basically allow you script Cast in order to, for example, integrate with Github (we may ship a plugin for this), buildbot or other build related infrastructure.

Let me know if that answers your question, or if you have others - and again, sorry it took so long to get back to you on this.

[1] http://cast-project.org/docs/references/hooks/

[2] http://cast-project.org/docs/references/templates/

[3] http://cast-project.org/docs/references/data-files/

[fairwinds]

Hi. I appreciate your reply. There is little reason from my view that
cast could not perform server configuration. Either shell script or js
is sufficient to execute the necessary tasks. Most admins are working
with some form of server template to start with. In the case of
virtualization (or even something like kickstart with Redhat/CentOS)
this can be quite specialized. I also work with some generalized
automation so that so that if I need resources other than my own gear
(ie. a dedicated server or cloud server) and have a more general
starting point, that this type of automation may be used to perform
tasks to build up the server with appropriate software and
configuration, deploy the app, and hook up any monitoring. The app
does not run in isolation and the underlying system libs may need to
be updated, reinstalled or some configuration rerun. This may be for
any number of reasons including security, to take advantages of
featured in upgrades, something broke, etc. For virtualization, the
server is often throw away which is fine. If there are issues, it is
thrown away and a new instance started. On dedicated hardware where
you've got a block of ips fixed to an interface, not so much.

At this point, I will try some things, perhaps the pre, post hooks may
be sufficient to handle the sort of arbitrary tasks I am speaking of.
I have my own gear in addition to working with dedicated machines and
cloud servers. I will experiment on a dedicated machine as this poses
more challenges than an app server template that is pretty much a
ready to run server instance.

On Jun 3, 9:55 pm, russell_h <russellhaer...@gmail.com> wrote:
> Sorry, this sort of slipped under my radar. Let me know if I'm
> misunderstanding you, but I think I can address this as two separate issues:
>

>    1. Server buildout, configuration and management - we're relatively

>    content to leave this to existing configuration management systems.

>    2. "Application level" tasks. This is more what we're interested in