Annotated network json file
This will attempt to describe each section of the network json file. This with the Network barclamp descriptions should explain the file.
This is the start of the JSON file. All barclamp template files need their id. The id is in the form: "bc-template-<barclamp name>". The description field is a quick comment on what this is.
{
"id": "bc-template-network",
"description": "Instantiates network interfaces on the crowbar managed systems. Also manages the address pool",The attributes map is reserved for the barclamps configuration data. This map gets applied to the node a set of normal role attributes (in chef terms). The network map is used to help generate a namespace for the barclamp on the node's attributes. When accessing this data from the node in a chef recipe, the node[:network] variable has all this data.
"attributes": {
"network": { "start_up_delay": 30,
"mode": "single",
"teaming": {
"mode": 6
},The start_up_delay defines the number of seconds (30 by default) that the system should pause once networks are configured. The mode defines name space to restrict some of the other configuration options. This allows multiple configurations to be created and switched as needed on the fly. The teaming map defines the default linux bonding mode if linux bonding is requested from the conduit maps.
The interface map is used to generate a normalized list of interface. On some systems, the interfaces don't always enumerate the way we think they should. This usually happens with added ethernet adapters. The crowbar ohai plug uses the /sys/class/net files to determine bus of each adapter. With that information and these maps, the system generates a mapping of physical interfaces to logical interfaces that the system will use for conduits.
The map is really a list of maps. The list is processed in order. The first matching map is used to enumerate the interfaces.
The map contains a pattern and a list of strings presenting the buses. The pattern is a regex string that will be compared to the systems product name as returned by dmidecode. The example below makes sure that the 4 loms on a PowerEdge R610 are the first ones listed. If a bus is not listed or a map is not found, the current network order is used. The bus order is the path listed in the PCI for that device as derived from the /sys/class/net/<device> files. Depending upon operating system (redhat and ubuntu are different), this is either the contents of the /sys/class/net/<device>/device file or the path specified by the symbolic link of /sys/class/net/<device>.
"interface_map": [
{
"pattern": "PowerEdge R610",
"bus_order": [
"0000:00/0000:00:01",
"0000:00/0000:00:03"
]
},Once we have an ordered list of interfaces, we can create conduits for network traffic. A conduit is a single or multiple interfaces bonded together that can hold tagged or untagged and bridged or unbridged traffic. It is a way to name the logically mapped physical NICs into wires for traffic.
The conduit map works like the interface map. It is a list of entries that are processed in order to generate a list of conduits that can then have networks attached. The first entry to match the pattern is used. The map contains a default pattern that will always match.
The pattern for conduit matching consists of three values separated by a /. The first element is mode. This is the value specified in the global parameters section. The default file supports a single, dual, and team modes. This can be anything. The maps are consulted to get the conduits based upon that value. The second value is the number of 1Gb interfaces the node has. This part allows you to generate different conduit sets based upon the number of interfaces. This way a 2 interface could have a single bond; while a four interface system could have 2 bonds with networks split between them. The third component defines a role that the node should have. This allows you to say things like hadoop-masternamenode should have this networking configuration, while a hadoop-datanode has another. The interesting thing is that all three components can use regular expressions. This way you can do wild card matching.
In the example immediately below, the system would match nodes with a global mode value of "team", any number of interfaces, and any roles.
Once matched, the conduit_list is recorded and the interfaces define. The conduit_list is a map of interface names (can be anything) and their logical interface list and an optional team_mode override. If more than one interface is used, then the interface is assumed to be a bond and the global team_mode is used unless overridden by the local value. The if_list uses the logical names 1g1 (read as 1gb first interface). 1g2, 1g3, ... You can see that one day the system will be expanded to 10Gb, but not yet.
These interface names in the name (e.g. intf0) are used by the networks to indicate what physical connection they are on.
"conduit_map": [
{
"pattern": "team/.*/.*",
"conduit_list": {
"intf0": {
"if_list": [ "1g1", "1g2" ],
"team_mode": 6
},
"intf1": {
"if_list": [ "1g1", "1g2" ],
"team_mode": 6
},
"intf2": {
"if_list": [ "1g1", "1g2" ],
"team_mode": 6
}
}
},The network map is just that. A set of networks that are available for the system to pull addresses from. The parameters are pretty straight forward. The conduit is the interface from a conduit map entry. The vlan is the vlan id to use for this network if we should use vlans as specified by the use_vlan value. The add_bridge indicates if a bridge interface should be added on top of interface for this network.
The final tricky parameter is the ranges map. When asked for an IP address, the network barclamp uses the network name and a range name to pull the address from. The range map should have at least "host", but others can be specified as well. Each barclamp can use these ranges how they like. The deployer barclamp uses the admin and host ranges on the admin network to assign the operational admin addresses for nodes. The nova barclamp uses the nova_fixed network for defining the private network of the virtual machines. It reserves the address not in the DHCP range for servers (not virtual machines).
"public": {
"conduit": "intf1",
"vlan": 300,
"use_vlan": true,
"add_bridge": false,
"subnet": "192.168.122.0",
"netmask": "255.255.255.0",
"broadcast": "192.168.122.255",
"router": "192.168.122.1",
"ranges": {
"host": { "start": "192.168.122.2", "end": "192.168.122.49" },
"dhcp": { "start": "192.168.122.50", "end": "192.168.122.254" }
}
},The deployment section contains barclamp control configuration. These parameters are more about controlling the barclamp itself than the actual thing the barclamp is managing. It uses a similar name space separation scheme like the attributes section.
"deployment": {
"network": {The final parts define barclamp controls. The crowbar-revision tracks the number of times this proposal has changed. The elements map builds up a list of each node assigned to the barclamp what function it has. The element_order controls how proposals are applied to the system as a whole and in what order. This is a topic for a whole other page. The section contains an environment declaration that gets filled in when the barclamp instantiated to assist in search for specific barclamp instances. The transition variables define when the barclamp's transition function is called if at all. In this case, any node transitioning to the "discovered" state will cause the network barclamp to be notified.
All barclamps have a section like this.
"crowbar-revision": 0,
"elements": {},
"element_order": [
[ "network" ]
],
"config": {
"environment": "network-base-config",
"mode": "full",
"transitions": true,
"transition_list": [ "discovered" ]
}The full file all together.
{
"id": "bc-template-network",
"description": "Instantiates network interfaces on the crowbar managed systems. Also manages the address pool",
"attributes": {
"network": {
"start_up_delay": 30,
"mode": "single",
"teaming": {
"mode": 6
},
"interface_map": [
{
"pattern": "PowerEdge R610",
"bus_order": [
"0000:00/0000:00:01",
"0000:00/0000:00:03"
]
},
{
"pattern": "PowerEdge R710",
"bus_order": [
"0000:00/0000:00:01",
"0000:00/0000:00:03"
]
},
{
"pattern": "PowerEdge C6145",
"bus_order": [
"0000:00/0000:00:04",
"0000:00/0000:00:02"
]
},
{
"pattern": "PowerEdge C2100",
"bus_order": [
"0000:00/0000:00:1c",
"0000:00/0000:00:07",
"0000:00/0000:00:09",
"0000:00/0000:00:01"
]
},
{
"pattern": "C6100",
"bus_order": [
"0000:00/0000:00:01",
"0000:00/0000:00:03",
"0000:00/0000:00:07"
]
},
{
"pattern": "product",
"bus_order": [
"/0/100/1",
"/0/100/2"
]
}
],
"conduit_map": [
{
"pattern": "team/.*/.*",
"conduit_list": {
"intf0": {
"if_list": [ "1g1", "1g2" ],
"team_mode": 6
},
"intf1": {
"if_list": [ "1g1", "1g2" ],
"team_mode": 6
},
"intf2": {
"if_list": [ "1g1", "1g2" ],
"team_mode": 6
}
}
},
{
"pattern": "dual/.*/.*",
"conduit_list": {
"intf0": {
"if_list": [ "1g1" ]
},
"intf1": {
"if_list": [ "1g2" ]
},
"intf2": {
"if_list": [ "1g1" ]
}
}
},
{
"pattern": "single/.*/.*",
"conduit_list": {
"intf0": {
"if_list": [ "1g1" ]
},
"intf1": {
"if_list": [ "1g1" ]
},
"intf2": {
"if_list": [ "1g1" ]
}
}
},
{
"pattern": ".*/.*/.*",
"conduit_list": {
"intf0": {
"if_list": [ "1g1" ]
},
"intf1": {
"if_list": [ "1g1" ]
},
"intf2": {
"if_list": [ "1g1" ]
}
}
},
{
"pattern": "mode/1g_adpt_count/role",
"conduit_list": {
"intf0": {
"if_list": [ "1g1" ]
},
"intf1": {
"if_list": [ "1g1" ]
},
"intf2": {
"if_list": [ "1g1" ]
}
}
}
],
"networks": {
"storage": {
"conduit": "intf1",
"vlan": 200,
"use_vlan": true,
"add_bridge": false,
"subnet": "192.168.125.0",
"netmask": "255.255.255.0",
"broadcast": "192.168.125.255",
"ranges": {
"host": { "start": "192.168.125.10", "end": "192.168.125.239" }
}
},
"public": {
"conduit": "intf1",
"vlan": 300,
"use_vlan": true,
"add_bridge": false,
"subnet": "192.168.122.0",
"netmask": "255.255.255.0",
"broadcast": "192.168.122.255",
"router": "192.168.122.1",
"ranges": {
"host": { "start": "192.168.122.2", "end": "192.168.122.49" },
"dhcp": { "start": "192.168.122.50", "end": "192.168.122.254" }
}
},
"nova_fixed": {
"conduit": "intf1",
"vlan": 500,
"use_vlan": true,
"add_bridge": true,
"subnet": "192.168.123.0",
"netmask": "255.255.255.0",
"broadcast": "192.168.123.255",
"router": "192.168.123.1",
"ranges": {
"router": { "start": "192.168.123.1", "end": "192.168.123.1" },
"host": { "start": "192.168.123.2", "end": "192.168.123.49" },
"dhcp": { "start": "192.168.123.50", "end": "192.168.123.254" }
}
},
"nova_floating": {
"conduit": "intf1",
"vlan": 400,
"use_vlan": true,
"add_bridge": false,
"subnet": "192.168.126.0",
"netmask": "255.255.255.0",
"broadcast": "192.168.126.255",
"ranges": {
"host": { "start": "192.168.126.2", "end": "192.168.126.255" }
}
},
"bmc": {
"conduit": "bmc",
"vlan": 100,
"use_vlan": false,
"add_bridge": false,
"subnet": "192.168.124.0",
"netmask": "255.255.255.0",
"broadcast": "192.168.124.255",
"ranges": {
"host": { "start": "192.168.124.162", "end": "192.168.124.240" }
}
},
"bmc_vlan": {
"conduit": "intf2",
"vlan": 100,
"use_vlan": true,
"add_bridge": false,
"subnet": "192.168.124.0",
"netmask": "255.255.255.0",
"broadcast": "192.168.124.255",
"ranges": {
"host": { "start": "192.168.124.161", "end": "192.168.124.161" }
}
},
"admin": {
"conduit": "intf0",
"vlan": 100,
"use_vlan": false,
"add_bridge": false,
"subnet": "192.168.124.0",
"netmask": "255.255.255.0",
"broadcast": "192.168.124.255",
"router": "192.168.124.1",
"ranges": {
"admin": { "start": "192.168.124.10", "end": "192.168.124.11" },
"dhcp": { "start": "192.168.124.21", "end": "192.168.124.80" },
"host": { "start": "192.168.124.81", "end": "192.168.124.160" },
"switch": { "start": "192.168.124.241", "end": "192.168.124.250" }
}
}
}
}
},
"deployment": {
"network": {
"crowbar-revision": 0,
"elements": {},
"element_order": [
[ "network" ]
],
"config": {
"environment": "network-base-config",
"mode": "full",
"transitions": true,
"transition_list": [ "discovered" ]
}
}
}
}