-
Notifications
You must be signed in to change notification settings - Fork 1
fire
There have been at least 3-4 different Nodee implementations over the past 2 years -- none of which do what the original plan called for so "Fire" is just a new name to make it easier to distinguish them. "Fire" as in "Fire up". I know the name is lame, but so is Nodee :-).
Fire is a daemon process that listens to a pre-defined port and presents the workd with a REST API. The REST API can be used to
- start services
- stop services
- list what services are running
As part of starting services, Fire has the ability to install software
packages. It does this using the copkg package manager library.
For now we will not concern ourselves with uninstalling packages.
Fire accepts POST requests for starting services on /services, GET
requests to list the running services and DELETE requests to stop
services.
Fire is not supposed to have any brains. How dumb is an interesting
question. This means that in the first version we wish fire to just
be a thin veil over the script.d/start.py script and the
script.d/stop.py scripts. It should just accept requests on the
REST interface, translate them to command lines and run them. Using
the package manager to install things when needed.
In the future we might want to have goal-tracking and automatic restart of services that stop/crash, but first we should agree that we need this.
Fire should have minimal zookeeper integration and should not depend
on Zookeeper to be able to operate. This is important to make it run
on developer workstations without too much hassle. Since only one
Fire instance should run on any machine at any given time, Fire should
contact Zookeeper and create an ephemeral node in the /fire/nodes
directory. The ephemeral node should be named after the hostname used
to reach the host within the datacenter.
Fire should have NO Cloudname integration. At least not initially.
Finding all live Fire nodes in a cell is a matter of listing the
nodes under /fire/node.
The ephemeral node made by a Fire instance when it starts up may be used to list what services are running on that node *as a conveience for tools that browse the nodes.
Fire may be used to serve the runtime directory of services or parts
of the runtime directories. These should probably be exposed under:
/services/1.idee.prod.trd/log, /services/1.idee.prod.trd/console,
/services/1.idee.prod.trd/etc and so on.