flocker-node: list local containers managed by flocker about flocker HOT 8 CLOSED

As a first pass, we can assume flocker is in charge of all geard units, or we can do simple namespacing scheme and only assume we control things prefixed with "flocker-".

Over long term we may want to run more than one application on a cluster, which means we need way to differentiate between different applications' units. So may as well start namespacing now. And this also means you can run e.g. flocker infrastructure with geard for bootstrapping purposes and not have it break, etc..

from flocker.

We probably want to require all units that we don't intend to be running to be deleted, rather than simply stopped. Otherwise e.g. started and then failed units will still be there if we only stop them.

from flocker.

Here's the API for listing geard units:

$ curl http://192.168.200.3:43273/containers
{"Containers":[{"Id":"sshd-1","ActiveState":"failed","SubState":"failed","LoadState":"loaded"}]}

from flocker.

Blocked on #54.

from flocker.

We should probably just not bother with the namespacing idea for the first release.

from flocker.

@exarkun My design proposal:

Simply do the above query, and return Deferred firing with dictionary mapping container name to activation state value. The activation state is useful insofar as it tells you if the container is installed but not running ("inactive"), starting ("activating"), running ("active"), failed ("failed") or stopped (either "failed" or "inactive" apparently). I would like to include the string as is because this is list may not be complete and I'm having a hard time finding docs listing the full list...

from flocker.

This sounds reasonable. It may be worth representing the container as a nice object (characteristic) with a couple attributes - name and activation state - and use those as values, rather than just a lot of strings. That's probably not much harder and gives us an easy way to expand the state associated with containers later (or give them behavior).

Please go ahead.

from flocker.

In #32 (comment) @itamarst wrote:

I would like to include the string as is because this is list may not be complete and I'm having a hard time finding docs listing the full list...

I think the states come from systemd. Some are documented here:

• http://www.freedesktop.org/software/systemd/man/systemd.html#Concepts

Units may be "active" (meaning started, bound, plugged in, ..., depending on the unit type, see below), or "inactive" (meaning stopped, unbound, unplugged, ...), as well as in the process of being activated or deactivated, i.e. between the two states (these states are called "activating", "deactivating"). A special "failed" state is available as well, which is very similar to "inactive" and is entered when the service failed in some way (process returned error code on exit, or crashed, or an operation timed out). If this state is entered, the cause will be logged, for later reference. Note that the various unit types may have a number of additional substates, which are mapped to the five generalized unit states described here.

from flocker.