fcoe

Table of Contents

1. Module Description - What the module does and why it is useful
2. Setup - The basics of getting started with fcoe
   • What fcoe affects
   • Setup requirements
3. Usage - Configuration options and additional functionality
   • Parameters (and default values)
   • Sample Usage
4. Limitations and Known Issues
5. Development - Guide for contributing to the module
6. TODO
7. Contributors

Module Description

The fcoe module automates the Configuration and Deployement of Fibre-channel over Ethernet (FCoE) interface(s) on Linux Systems

What fcoe affects

• The following FCOE Network Interface Configuration files:
  1. /etc/fcoe/cfg-ethX
  2. /etc/sysconfig/network-scripts/ifcfg-ethX

Setup Requirements

fcoe requires:

• pluginsync = true (Puppet Configuration)
• puppetlabs/stdlib (>= 4.9.0)

Usage

Parameters

There are 07 main parameters used to control the fcoe behaviours:

fcoe_interface : fcoe Ethernet Interface (ethX)
String that specifies the fcoe Interface Name (not optional).

• default:
  -- No default parameter, that must be set (example: eth2)

fcoe_enable : Enable/Disable FCoE service at the Ethernet port
String to Enable/Disable FCoE service at the Ethernet port. Normally set to "yes"

• default: yes

dcb_required : Indicate if DCB service is required at the Ethernet port
String to Indicate if DCB service is required at the Ethernet port.

• default: no

auto_vlan : Indicate if VLAN discovery should be handled by fcoemon
String to Indicate if VLAN discovery should be handled by fcoemon.

• default: yes

fcoe_mode : Indicate the mode of the FCoE operation, either fabric or vn2vn
String to Indicate the mode of the FCoE operation,
either fabric or vn2vn.

• default: fabric

fip_resp : Indicate whether to run a FIP responder for VLAN discovery in vn2vn mode
String to Indicate whether to run a FIP responder for VLAN discovery in vn2vn mode,

• default: no

fcoe_mtu : Settings the default MTU for the FCOE Interface
String to set the default MTU for the FCOE Interface, The default value is set as undef (leaving the MTU to its default value), This settings affects ifcfg-ethX Interface

• default: undef

Sample Usage

To configure an ethX interface by accepting the default values listed above, specify only the fcoe Interface parameter in the fcoe::interface defined type.
As with any defined typed, this can be evaluated multiple times with different parameters.
The following examples configures both eth2 and eth3 as FCOE Interfaces with default settings:

fcoe::interface { 'eth2':
    fcoe_interface  => 'eth2',
}
fcoe::interface { 'eth3':
    fcoe_interface  =>'eth3',
}

To modify some of the default settings,

fcoe::interface { 'eth2':
    fcoe_interface  => 'eth2',
    fcoe_enable     => 'yes',
    dcb_required    => 'no',
    auto_vlan       => 'yes',
    fcoe_mode       => 'fabric',
    fip_resp        => 'no',
    fcoe_mtu        => '9000',
}
fcoe::interface { 'eth3':
    fcoe_interface  =>'eth3',
    fcoe_enable     => 'yes',
    dcb_required    => 'no',
    auto_vlan       => 'yes',
    fcoe_mode       => 'fabric',
    fip_resp        => 'no',
    fcoe_mtu        => '9000',
}

Below is the same configuration using Hiera and create_resources

  # FCOE
  # Create a hash from Hiera Data with the FCOE Interfaces
  $myFcoeIfaces = hiera('fcoe::interface', {})
  # With Create Resource Converts a hash into a set of resources
  create_resources('fcoe::interface', $myFcoeIfaces)

On my Hiera Yaml files,

---
fcoe::interface:
  'eth2':
    fcoe_interface   : 'eth2'
    fcoe_enable      : 'yes'
    dcb_required     : 'no'
    auto_vlan        : 'yes'
    fcoe_mode        : 'fabric'
    fip_resp         : 'no'
    fcoe_mtu         : '9000'
  'eth3':
    fcoe_interface   : 'eth3'
    fcoe_enable      : 'yes'
    dcb_required     : 'no'
    auto_vlan        : 'yes'
    fcoe_mode        : 'fabric'
    fip_resp         : 'no'
    fcoe_mtu         : '9000'

Limitations and Known Issues

Development

I happily accept bug reports and pull requests via github,
https://github.com/stivesso/fcoe

• Fork it
• Create a feature branch
• Write a failing test
• Write the code to make that test pass
• Refactor the code
• Submit a pull request

TODO

• Add Support for other OS Family (Debian, SuSe, Solaris...)

Contributors

• The module is written and being maintained by: stivesso