Skip to end of metadata
Go to start of metadata


Session Title: Managed Nodes Part 2

Convener:
Matt Ray

Participants:
Rob Hirschfeld
Greg Althaus
George Moberly
Chris Brown
Kyle Bader
Carl Perry
Sean P. Kane
Nathaniel Eliot

Summary of discussions:

In order to extend the reach of Chef into managing nodes that cannot run the chef-client, Chef needs to be extended to support the concept of a "Managed Node". Managed Nodes may be network devices (switches, firewalls, load balancers, etc.), network storage, databases and any other device that we may configure via an API or other tools, but we want to treat it as a Node. The Managed Node needs to behave identically to Nodes in many respects, yet have a few additional capabilities exposed. Other Nodes will have to perform these management operations as "Management Providers" without interfering with their own configuration as a Chef Node.

  • MANAGED NODES
    • Extension of the Node object within Chef.
    • Appear in searches for Nodes.
    • Have a Management Provider that provides the configuration services for that Managed Node.
    • Have a list of allowed Management Providers to use for configuring the node.
    • The list of Nodes allowed to manage a particular Managed Node are stored on the Managed Node.
    • Resources executed against the Managed Node will be supported by Providers specific to that device.
  • MANAGEMENT PROVIDERS
    • Nodes that configure Managed Nodes are referred to as Management Providers.
    • Management Providers have no knowledge that they are providing this service.
    • Security or network topology concerns are addressed by assigning Management Providers to the Managed Nodes.
    • Providers may install additional packages or tools on the Management Provider, but not alter the Management Provider otherwise.
    • "knife ssh" calls will pass through to the Management Provider for the Managed Node.
  • ATTRIBUTES
    • node.managed?: boolean for whether or not this is a Managed Node
    • node.manager: the Node that is currently acting as the Management Provider for this node
    • node.allowed_managers: list of Nodes that are allowed to act as Management Providers for this node.
  • KNIFE
    • All of the "knife node" operations are available for managing Managed Nodes.
    • "knife search node" will return all Nodes, including Managed Nodes.
    • "knife node managed add NODE PROVIDER" will add a new allowed Management Provider
    • "knife node managed remove NODE PROVIDER" will remove an allowed Management Provider
    • "knife node managed set NODE PROVIDER" will set the Management Provider for the node
  • CHEF-CLIENT
    • chef-client currently only supports a single Node, needs to support multiple Managed Nodes.
    • chef-client needs to support Managed Nodes with schedules independent of the Node itself.
    • chef-client needs to be safe for multiple simultaneous runs
    • ohai is currently run as an on-Node application, need to extend it to work remotely or write a new 'ohaithere' application.
    • ohaithere will need to support plugins for supporting multiple remote retrieval methods, yet still return ohai-compatible data
  • DISCUSSION
    • What is the best way to manage client keys and access credentials for Managed Nodes? Encrypted data bags?
    • How does the Managed Provider find that it has a Managed Node and start managing it? Check during every chef-client run?
    • Do we want Managed Nodes to have an additional search and knife keyword (ie. 'knife managed' and/or 'search(:managed, ":")')?
    • Does the Chef Server assign the node.manager from the node.allowed_managers randomly or is always explicit? If random, when do we reassign?
    • Do we need to extend the chef-client cookbook to support Managed Nodes?
    • knife managedbootstrap managed_node -r 'recipe[blah],role[blahblah]' -managers "a.foo.com, b.foo.com, c.foo.com"

Rob's notes from the session

Managed Nodes are entities that cannot run chef-client.  There are needs to collect information from them (ohai).
Management Provider will be a HWRP (heavy weight resource provider) that does the implementation.  For example, the firewall cookbook is a reference implementation.
Terms are subject to change if you have a better suggestion.
Managed nodes are used where the node cannot take actions on their own.  A node would make a configration request on the managed node.  The managed node would action on that request during its next chef-client request.
We need to treat managed nodes as both a service (actuator / request) and a configuration (node / managed entity).  The goal is for the later.  In the later case, the node is assumed to have all the information it needs to do the configuration via Chef.
  
Some configuration may be out of band for setup; however, the node will have all the data that is needed.
This is not just about actions, it is also about search ability.
Use case - have a SAN managed nodes.  Cookbook could ask the node for a LUN.  Node would be able to discover available storage and create a new LUN.
  
Implementation discussion - knife & chef-client are not setup to have mulitple entities on the same system.  This can create challenges.
Open question - do we need to track relational data between nodes & managed nodes?
Timeframe 
  - Opscode says this is a high priority to get into the product
  - Dell is working in the next quarter on a hack pre-implementation that does this in our context

  • Managed Nodes are entities that cannot run chef-client.  There are needs to collect information from them (ohai).
  • Management Provider will be a HWRP (heavy weight resource provider) that does the implementation.  For example, the firewall cookbook is a reference implementation.
  • Terms are subject to change if you have a better suggestion.
  • Managed nodes are used where the node cannot take actions on their own.  A node would make a configration request on the managed node.  The managed node would action on that request during its next chef-client request.
  • We need to treat managed nodes as both a service (actuator / request) and a configuration (node / managed entity).  The goal is for the later.  In the later case, the node is assumed to have all the information it needs to do the configuration via Chef.
  • Some configuration may be out of band for setup; however, the node will have all the data that is needed.
  • This is not just about actions, it is also about search ability.
  • Use case - have a SAN managed nodes.  Cookbook could ask the node for a LUN.  Node would be able to discover available storage and create a new LUN.
  • Implementation discussion - knife & chef-client are not setup to have mulitple entities on the same system.  This can create challenges.
  • Open question - do we need to track relational data between nodes & managed nodes?

Timeframe 

  - Opscode says this is a high priority to get into the product

  - Dell is working in the next quarter on a hack pre-implementation that does this in our context

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

Discussion of design needs to move to mailing lists and Opscode Product Management will prioritize for development. A number of users have expressed the plan to start implementing stop-gap measures in the meantime.

Talk about External Entity Hack and Design to mode intermediate solution forward.
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.