Management of External Entitites

Convener:
Rob Hirschfeld, Greg Althaus, Matt Ray

Participants:
About 20+ people including Alex Howells (very vocal)
Kurt Yoder
Nathaniel Eliot

External entities are nodes that act on something that the place the code is run does not have direct access to. Sort of like a proxied node.

Use cases:

switch configuration
Blade chassis configuration
SAN config
manual steps
non-root control
external authentication
SaaS endpoints: AWS's security groups, ELB, Route 53, et. al., and similar offerings

Notes:

Hack way: put agent into chroot or LXE container. More on this [chef:External Entity Hack and Design]
Looking for a better way - needs an execution environment
Challenge - external entities need network access (or serial) from limited locations/paths
use case - an external database could be managed
part of the problem is how do you model the state of these external entities? Their state is controlled by the item they proxy for!
Cookbooks become like services (see [chef:Cookbook As Services Pattern])
Changes could happen outside of the node's context - this is tricky to manage
missing - we need a dependency graph for the switch, chassis, SAN etc
- these are links, not nodes. there is a real dependency between these types of items
- Crowbar will model them using roles, but that's a hack
we (Dell) are putting a lot of information as extra attributes (generally roles)
some things are complex, it helps to treat them as nodes
Matt Ray will do a session on "Managed Nodes" requirements. He called external entities, managed nodes. Session: [chef:Managed Nodes Part 2]
Can use by extending Actuate?
Alex H felt that the Actuator pattern could do a lot of this
These are not light weight services! The node cannot invoke items that we need to be configured by external entities.
Directed graphs are needed but are hard to implement in databags

Overall, people saw a lot of uses for this functionality.

What will we do now? What needs to happen next?