One might assume that repeatedly calling the create() method on a newly-instantiated proxy object would be idempotent, but it is not. This certainly falls under the "don't do that, then!" rubric, but it's worth noting. The source of this issue is that the new commit has the old commit as its parent — so we will have distinct commits (since a commit cannot descend from itself) with the same tree. Whether or not this behavior is desirable is another matter, but it is a straightforward fix if it isn't.

Example transcript from the Python client follows (and clearly shows a new commit for each create() call).

>>> import wallaroo
>>> cm = wallaroo.client.ConnectionMeta(host="localhost", port=8000)
>>> foo = cm.make_proxy_object("node", "foo")
>>> 
>>> for i in range(0, 10):
...     foo.create()
...     foo.refresh()
...     print "%r, %r" % (foo.attr_vals, foo.cm.how.to_q())
... 
{u'memberships': [], u'provisioned': True, u'identity_group': u'+++acbd18db4cc2f85cedef654fccc4a4d8', u'name': u'foo'}, {'commit': '4502374ca95a17f9c73b59cf59d19f36a74131de'}
{u'memberships': [], u'provisioned': True, u'identity_group': u'+++acbd18db4cc2f85cedef654fccc4a4d8', u'name': u'foo'}, {'commit': 'b0f02b4862ac7c06abecbf680c0c947b2edcf122'}
{u'memberships': [], u'provisioned': True, u'identity_group': u'+++acbd18db4cc2f85cedef654fccc4a4d8', u'name': u'foo'}, {'commit': '297690c61d66d0191747eafdbe1cdda3334e1573'}
{u'memberships': [], u'provisioned': True, u'identity_group': u'+++acbd18db4cc2f85cedef654fccc4a4d8', u'name': u'foo'}, {'commit': '362eb204877fe80c9f73dcda7968dffd89b4c77e'}
{u'memberships': [], u'provisioned': True, u'identity_group': u'+++acbd18db4cc2f85cedef654fccc4a4d8', u'name': u'foo'}, {'commit': '66e6b25f531faee9a91495fbfce6402147e6b99c'}
{u'memberships': [], u'provisioned': True, u'identity_group': u'+++acbd18db4cc2f85cedef654fccc4a4d8', u'name': u'foo'}, {'commit': '84a8616101770adbbd99c692a98bbb838d0b3c32'}
{u'memberships': [], u'provisioned': True, u'identity_group': u'+++acbd18db4cc2f85cedef654fccc4a4d8', u'name': u'foo'}, {'commit': '6fc8f99a184445d9a60bed4a67abf6f01b526533'}
{u'memberships': [], u'provisioned': True, u'identity_group': u'+++acbd18db4cc2f85cedef654fccc4a4d8', u'name': u'foo'}, {'commit': '2981568fae27bf0b4dc56582b79db149c0330205'}
{u'memberships': [], u'provisioned': True, u'identity_group': u'+++acbd18db4cc2f85cedef654fccc4a4d8', u'name': u'foo'}, {'commit': '0f42862e46e4aab2d28abed7eaa78e894160d103'}
{u'memberships': [], u'provisioned': True, u'identity_group': u'+++acbd18db4cc2f85cedef654fccc4a4d8', u'name': u'foo'}, {'commit': '0ade7d13b7eb4e66d2bb199136ea5edabe6edebd'}

Currently validation failures return structured error messages at the Erlang level, but we return failures as big ol' strings at the REST level. The structured failure tuples need to be translated to structures that mochijson can understand, e.g.

[{K, V}, ...]

becomes

{struct, [{K, V}, ...]}

and

[foo, bar, blah]

becomes

{array, [foo, bar, blah]}

Raw tuples need to become dicts so that they can be encoded as JSON objects.

This is a good candidate for something to put in to wallaroo_web_common

I'm not committed to any particular query string syntax or level of constraint support, but filtering entities in list requests is desirable. E.g.,

GET http://localhost:8000/nodes?tag=current

would return all nodes as of the currently-active configuration, as it does now. However,

GET http://localhost:8000/nodes?tag=current&constraint_provisioned=true

would return all provisioned nodes as of the currently-active configuration,

GET http://localhost:8000/nodes?tag=current&constraint_memberships_include=Execute+Nodes

would return all nodes that are members of the Execute Nodes group.

We have an implementation of Store#getMustChangeParams in the client library. A better implementation would use query parameters to filter entity lists at the API level (depends on issue #6).

Running either:
wallaby inventory -c "provisioned && last_checkin < 2.weeks_ago" | grep -v "Console Connection Established"

Or

wallaby inventory -c '!provisioned && last_checkin < 2.weeks_ago' | grep -v "Console Connection Established"

Fails and produces the following error:

fatal: /usr/lib/ruby/1.8/net/http.rb:560:in initialize': Insecure operationinitialize' at level 4

wallaby_config:generic_lookup/5 supports a default argument which is returned unmodified if no cached config is found for a given node or group. It should also support passing in a function as the default argument to calculate the configuration if no cached config is found.

The wallaby-classic client libraries both return a group proxy object when asked for a node's identity group. The wallaroo clients return a group name. Wallaroo's behavior should be consistent with Wallaby's here.

Currently, Wallaroo calculates and validates new configurations for every node upon activation. There is internal infrastructure support for using an explicit dirty list; we should use it.

Currently Node#getConfig is only implemented when no optional arguments are supplied. The only option that Wallaby classic supported was version. Wallaroo will support getting configs for a particular version (i.e. commit), for a particular tag, or for a particular branch.