The network barclamp has 3 primary functions: - Keep track of what networks are available for other barclamps to use - Keep track of what addresses have been allocated to nodes. - Mapping conduits to physical interfaces, and make reality match our expectations.
Out of those functions, the first two are handled as part of the Crowbar framework, and the latter is handled by a Chef recipe that probably violates every design guideline for writing Chef recipes ever ( https://github.com/crowbar/barclamp-network/blob/master/chef/cookbooks/network/recipes/default.rbfor the brave) Keeping Track of Networks: In CB 1.x, you have to pre-seed the network barclamp with knowledge of all the networks you ever wanted to use, and if you made a misteak you were stuck with it unless you did some gnarly and racy messing with Chef. The network barclamp in CB 2.0 starts out knowing nothing, and you can create new networks at point of need using the REST api. In fact, the admin network that everything else relies on is created this way: curl --digest -u $(cat /etc/crowbar.install.key) \ -X POST http://localhost:3000/network/v2/networks \ -d "name=admin" \ -d "deployment=system" \ -d "conduit=1g0" \ -d 'ranges=[ { "name": "admin", "first": "192.168.124.10/24", "last": "192.168.124.11/24"},{"name": "host", "first": "192.168.124.81/24", "last": "192.168.124.254/24"},{"name": "dhcp", "first": "192.168.124.21/24", "last": "192.168.124.80/24"}]' This example also shows the minimum needed to define a basic network. Taken parameter by parameter, it says that: - You are creating a network named admin - That network should be available to all nodes in the system deployment and all its children (i.e, all of them), - It should communicate over the first gigabit Ethernet connection on all of the nodes that wind up using it - It will have 3 address ranges named "admin", "host", and "dhcp". Of these parameters, probably the one named "conduit" is the least obvious. Conduits (which can have more than one physical interface, by the way) are an abstraction Crowbar uses to work around the vagaries of trying to map Ethernet interface names back to actual physical ports, and will be explained in greater detail later. You can also pass additional parameters that control whether the network will run over a specific tagged VLAN, whether the interfaces in the conduit will be bonded (and what bonding mode to use if so), and whether the conduit will be attached to a bridge. There are some restrictions on creating networks: - Every network name must be globally unique. Once the deployment infrastructure is fleshed out this restriction will be relaxed to be unique within the scope of a deployment and its children. - No overlapping ranges allowed globally. This restriction will be eased along the lines of the naming restriction. - Conduits and teaming modes must either overlap perfectly or not at all globally. This restriction will also be eased along the lines of the naming restriction. Every network created via the API gets a free matching role that the core Crowbar framework uses when building and maintaining the noderole graph. Right now the network barclamp is authoritative and will ignore changes made by manipulating the state of the proxy role. Fixing that by fleshing out the proxy role's methods is on the list of things to do after we can bootstrap a cluster. Keeping Track of Addresses: The network barclamp in CB 2.0 allows you allocate and deallocate IP addresses from nodes, and this functionality works pretty much the same as it did in CB 1.x, except that the backing store is a table in sqlite instead of a Chef data bag. Each address allocation gets a free noderole that binds the network to the node and carries the address allocation with it. Mapping Conduits to Physical interfaces: The top portion of the network recipe linked to above handles the details -- by default, all Ethernet interfaces are sorted in ascending order by PCI address, but that ordering can be overridden on platforms where the PCI address order does not map in an obvious way, or where the embedded interfaces are not on the lowest PCI address. The idea is that we want the embedded interfaces to come first, interfaces in the PCI slot closest to the embedded ones second, and so on. One of the primary rules of conduits is that either they perfectly overlap or are disjoint, either as abstract definitions or after resolution to physical interfaces. All layers of the network barclamp work together to enforce this rule -- you cannot create a network definition via the API that violates that rule, and the network recipe will be modified to curl up and die if it finds that the conduit resolves to an overlapping physical interface configuration so that the framework will recognize the situation and alert the user. Making Reality Match Our Expectations: The rest of the network recipe concerns itself with figuring out what our desired set of physical interfaces, bonds, vlan interfaces, bridges, and address assignments should look like for the machine it is running on, moving from the current running config to the desired config while minimizing the risk of resetting a physical link, and writing out the proper distro-specific config files once it has made the changes (if any) using the appropriate low-level tools. To minimize the complexity of the overall scheme, only the network recipe concerns itself with actual physical interfaces -- it handles all the work of resolving a conduit to physical interfaces, building out the requested network configuration, and reporting what it resolved and did back to the framework. The code running in the Rails app deals entirely in terms of networks definitions, nodes, and address assignments between the two.
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
