cloudkick / cast Goto Github PK

What still needs to be done (main SConstruct):

1. Some kind of target which generates the distribution tarball. This target should do the following:
2. create temporary directory named build
3. copy all the Cast files in the build directory (.git should be excluded)
4. Move build/other/SConstruct to build/SConstruct
5. Move build/other/site_scons/ to build/
6. Create a tarball from the all the files in the build/ directory excluding paths listed in the paths_to_skip variable. We should probably use DistTar, because if we use Packageall the Cast files in the created tarball will be located in the build directory instead of cast-<version> and afaik you can't change that.

After this is done we need to test that the whole dist & install process is working.

Refactor existing code to use the new Jobs framework.

Will probably take a while a we will also need to modify a lot of the existing tests.

If the agent is started with this option enabled it should send the while stack-trace back to the client when the error is encountered.

This should help with the debugging in cases where the agent and client are located on a different server.

I'm getting a lot of SHA1 mismatches on uploads and haven't managed to figure out whats causing them yet. When repeatedly uploading the same file the agent will calculate incorrect hashes something like half of the time (and the incorrect values are never the same).

Spinner class should throw appropriate exception if tty.istty == false.

It should also throw an exception is window size cannot be determined.

cast instances upgrade --remote <remotename> <bundle> <version> always affects the default remote, not the specified remote.

Developer keys should be stored in a file on cast-project.org and all the releases should be signed.

This means "dist" SConstruct target must be modified to also sign the tarball.

Currently we expose most of our classes (Instance, Service, Bundle, etc..) through our API in a JSON format in some way or another.

The problem is that we always end up creating the actual response object which we than JSON.stringify and expose through the API in each service HTTP endpoint module separately. This means we have a lot unnecessary and repeated code there.

I think we should create a new class called Serializable from which all of our objects which are exposed through the API should inherit from.

This class should have a method named serialize(type='json', [attributes]).

This method should return a string which is a serialized version of this object.

The optional attributes parameter is an array and specifies which class attributes we want to serialize (defaults to 'all').

Attributes can also be callables, because in many cases we need to call some class method to get a value which we need.

attributes array could for example look like this: [ 'name', 'is_enabled()', 'status' ] (note: is_enabled is a callable / class method).

Ideally the method would be sync, but the problem is that most of the class methods which needs to be called to obtain some values are async so the actual method signature will in the end probably look something like this: serialize(type='json', [attributes='all'], callback)

Now that we have a nice test coverage report available we should aim to increase the coverage for the next release.

Imo going to around 80% shouldn't require much effort since there is a lot of low-hanging fruit.

Add a new step to the Cast builder which generates an HTML test coverage report.

Test coverage should also be accessible at http://www.cast-project.org/dev/test-coverage/.

This issue is blocked by issue #5.

In some places we still use now obsolete sys.pump function. We should it to use the new stream.pipe function.

getApiResponse should take an option object instead of bunch of arguments, we should also use sane defaults.

Conversation at #25 (comment)

There are many services that can do a graceful reload of their configuration (apache2) or of an entirely new binary (nginx) through the use of different signals. Being able to specify that cast uses a specific signal during an upgrade would be a nice feature.

Something like this:
cast instances upgrade --graceful servicename0 [email protected]

With maybe a {"restart_signal":"HUP"} in the cast.json so cast knows what that process responds to.

terminal module contains a bunch of utility functions for working with terminal and should be released as a separate project.

In some cases the post_prepare hook needs to exceed 50 seconds. It would be nice if the timeout could be increased by setting a new timeout in the cast.json file.

Spinner class should live in the terminal module.

Port existing tests to Whiskey 0.3.0

It should be fairly easy to do it.

We only need to make sure the user still uses install script for installing the agent, because the whole agent installation process is a bit more complicated and we don't have any plans yet for it to be NPM installable (at least for 0.2.0).

The npm package name should probably be cast-client.

Three files have incorrect permissions after the standard install that cause a normal user on the system not to be able to run cast.

The errors are:
Error: EBADF, Bad file descriptor '/opt/cast/cast/lib/extern/stacktrace.js'
Error: EBADF, Bad file descriptor '/opt/cast/cast/lib/extern/jspack/jspack.js'
Error: EBADF, Bad file descriptor '/opt/cast/cast/lib/util/version.js'

chmod a+rx filename
fixes the error and allows cast to run as a normal user.

Cast agent should listen for the SIGUSR signal and reload the settings file when this signal is received.

Because of the nature of the Node.js code and no hot-loading support only some changes can and should take an affect without a restart.

For the first release we should only support changes in the "plugins" part of the setting file to take an affect without restarting the agent.

Refactor existing HTTP endpoint modules and move all the application logic into control/ directory.

HTTP endpoint modules should be thin wrappers around the functionality defined in control/ directory. Basically those modules should be very small all the logic should live in other modules.

If this option is used the client will also print the whole stack trace on the error, not just the message.

Note: This option will only have an affect if the server is started with the --debug option.

Trying to integrate cast with buildbot and it seems like most failure circumstances return zero as their exit code...causing buildbot to think the steps ran successfully when they didn't.

Error: Failed to find a manifest file cast.json in /data/buildslave/projectname-cast/build
Error: Bundle projectname version [email protected] doesn't exist
Error: Missing required arguments: version

Probably more I haven't run into. I think any error should exit non-zero.

Does Cloudkick still use Cast or did the project stop? All activity seems like it stopped at the same time about 5 months ago. :-/

Refactor out rate-limiter module and release it as a separate project which can also be used as an Express middleware.

This step should produce a tarball which we can distribute.

Discussion at https://groups.google.com/forum/#!topic/cast-dev/ytqMkIf2Ga0

We will need to create multiple new Express middlewares:

• authentication middleware
• request throttling middleware
• etc.

handleCommand should take a callback and all the error reporting should be centralized.

Discussion at #25 (comment)

This middleware should drop the request if the body size is bigger then some defined threshold.

Body size threshold should also easily be changed on the per-route basis.

Most of the routes should be OK with a small default threshold, but there are some exceptions like PUT /bundles...

Currently dist tests fail on buildbot, check out why this happens and fix it.