(ARISTA-23) Implement snmp_notification provider #5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 27 commits
October 3, 2014 12:26
Without this patch the network_vlan specs are running against a live API service running on a VM. This is a problem because the specs are not running in isolation and will not run in other environments. This patch addresses the problem by stubbing out the API calls for the network_vlan provider.
Without this patch we aren't populating the mode attribute when getting all of the port channel resources using the instances class method. This method adds EosApi methods to obtain the mode using an text based API call to `show port-channel summary`. The utility methods then parse the text output and return structured data keyed by the Port-ChannelX name. The prefetch provider class method will almost always be the same for every EOS provider. Generalize it into a module that extends the provider class.
Without this patch the API REST endpoint is hard coded into the EosApi class. This is a problem because it is difficult to development and test different behaviors when there is and is not an API present. This patch addresses the problem by checking the environment variables for the API endpoint values.
Without this patch the netdev_stdlib dependency that includes the types are installed as a normal Gem bundle dependency. This is a problem because the source cannot easily be modified. This patch addresses the problem by using the location_for() approach to define the dependency as an environment variable.
Without this patch the network_interface provider is incorrectly trying to process Port-Channel interfaces as though they are ethernet interfaces. This is a problem because the Port-Channel interface does not have some attributes, such as duplex, which was causing an error while trying to list network interfaces when there are port channel interfaces defined on the target switch. This patch addresses the problem by processing only interfaces with a hardware type of 'ethernet'.
…ds module Without this patch the port_channel provider cannot easily convert speed values to and from the catalog values. This patch addresses the problem by moving the convert_speed() method from the network_interface provider to the EosProviderMethods module which is mixed into all providers. This avoids code duplication while also providing the ability to convert speed values in a consistent way across providers.
Without this patch the port_channel provider does not effectively manage the speed, duplex and description attributes of the port channel interface. This patch addresses the problem by moving the implementation methods for speed, duplex, and description from the network_interface provider into the shared EosProviderMethods module and re-using the methods for both the network_interface and the port_channel providers. The general approach to managing the speed and duplex settings are to do so on each of the member interfaces. When inspecting the current state of the system, the least common value for speed and for duplex are used in an effort to ensure all member interfaces remain consistent. Given a channel group with 4 members, if only one member has a different speed or duplex value then Puppet will detect that and enforce the managed value across all members of the channel group.
Without this patch the spec tests are not honoring the EOS_HOSTNAME, EOS_USERNAME, EOS_PASSWORD and EOS_PORT environment variables. This is a problem because it makes it difficult to save fixture data from the real API when working with the spec tests. This patch addresses the problem by moving the logic that looks up values from the environment out of the provider API helper method and into the EosApi instance initializer. This change ensure all initialized instances of the API look up configuration values from the environment in the same manner.
Without this patch the port_channel eos provider does not inspect the current state of the minimum links property. This is a problem because this property needs to be managed by Puppet. This patch addresses the problem by parsing the currently configured number of minimum links from the running configuration of the switch. If the text output from the switch does not contain a min-links line for the port channel, we safely assume there is a configured value of 0.
Without this patch the port_channel eos provider does not manage the state of the minimum links property on the target device. This patch addresses the problem by implementing the set_portchannel_min_links instance method on the EosApi class. The patch updates the port_channel provider to implement the minimum_links=(value) setter method to use this API method.
Without this patch the EOS port_channel provider does not obtain the current values for flowcontrol_send and flowcontrol_receive. This is a problem because we need to manage these values. This patch addresses the problem by iterating over the list of member interfaces and using the least common value across the set of member interfaces. This approach is intended to identify minor discrepancies across the set of member interfaces.
Without this patch the EOS port_channel provider does not manage the flow control send and receive values on the target device. This patch addresses the problem by configuring each member interface with the specified flow control send and receive values.
Without this patch Puppet has no implementation to inspect the current
state of the `network_snmp` resource from the target EOS device. This
is a problem because we need to manage the global SNMP state.
This patch partially implements the provider by reading all values
suitable for `puppet resource network_snmp` to operate as expected.
For example:
$ bundle exec puppet resource network_snmp
network_snmp { 'settings':
ensure => 'present',
contact => 'Jane Doe',
enable => 'true',
location => 'Westeros',
}
This patch also establishes the EosApi::SnmpMethods module which is
mixed into the EosApi class. The goal is to prevent the EosApi class
from growing too large by separating out related API methods into their
own module. This also provides clear introspection, for example from
pry, note how the included methods are broken out by the module they're
included from.
[3] pry(eos)> ls api
PuppetX::NetDev::EosApi::SnmpMethods#methods:
parse_snmp_enable snmp_attributes snmp_contact snmp_enable snmp_location
PuppetX::NetDev::EosApi#methods:
address password
all_interfaces port
all_portchannel_modes port_channel_destroy
all_portchannels portchannel_min_links
all_portchannels_detailed set_flowcontrol_recv
all_vlans set_flowcontrol_send
channel_group_create set_interface_description
channel_group_destroy set_interface_mtu
format_error set_interface_speed
get_flowcontrol set_interface_state
http set_portchannel_min_links
interface_set_channel_group set_vlan_name
interface_unset_channel_group set_vlan_state
parse_flowcontrol_single uri
parse_min_links username
parse_portchannel_active_ports vlan
parse_portchannel_configured_ports vlan_create
parse_portchannel_modes vlan_destroy
instance variables: @address @http @password @PORT @username
Without this patch fixtures are not being saved correctly when the data
being saved is a Ruby Hash object with symbols for keys. This is a
problem because the fixture save and restore process is not fully
isomorphic. Consider the following:
JSON.load(JSON.pretty_generate(foo: 1))
The actual result is `{"foo"=>1}` while the expected result is `{:foo =>
1}`.
This patch addresses the problem by saving YAML fixtures by default,
which correctly preserves Ruby native objects. The patch modifies the
fixture() method to first check for the existence of a YAML fixture, and
load that, then fall back to a JSON fixture if YAML is not present.
This approach provides backwards compatibility while avoiding future
problems with saved fixtures.
Without this patch the end user cannot enable or disable the global SNMP configuration using `puppet resource network_snmp settings enable=true` or `puppet resource network_snmp settings enable=false`. This patch addresses the problem by implementing the `enable=` setter method on the eos network_snmp provider. The implementation enables SNMP by creating a single community string named "public" with read only access to all objects. The implementation disables SNMP by using the `no snmp-server` command which is described as `disable Simple Network Management Protocol (SNMP) agent operation by removing all snmp-server commands from running-config.`
Without this patch the network_snmp provider cannot manage the contact property on the target device. This patch implements management by passing the contact value through to the `snmp-server contact ...` configuration command.
Without this patch the network_snmp provider cannot manage the location property on the target device. This patch implements management by passing the location value through to the `snmp-server location ...` configuration command.
… and location Without this patch there are no spec tests for the provider itself. This is a problem because there needs to be examples of how the provider is expected to behave in order to support future refactoring efforts. This patch addresses the problem by implementing behavior tests for each of the provider methods that are currently implemented.
Without this patch the ensure property is present on the provider. This is a problem because the type specification has a proposed change to remove the ensure property because there will only ever be a single resource of the network_snmp resource in a catalog. This patch addresses the problem by removing the ensure property from the provider to match the proposed type specification.
Method too long. =(
Method arguments not aligned. =(
Without this patch there is no provider for the snmp_community type. This patch partially addresses the problem by inspecting the current state of all SNMP communities defined on the target device and instantiating resources in puppet using the provider's `instances` class method. Remaining work is to augment the type to be ensurable and manage the state of the target resources in addition to inspecting their current state.
Without this patch a snmp_community resource with a non-existent ACL defined is parsed as 'emanon (non-existent)' when it should be parsed as 'emanon'. This is a problem because Puppet continually thinks the resource is out of sync when it is in fact in sync. This patch addresses the problem by updating the regular expression that parses the text output to deal with the presence of the trailing `(non-existent)` information.
Without this patch the creation behavior of the ensure property is not implemented in the snmp_community provider. This patch addresses the problem by implementing the EosApi#snmp_community_create method and wiring it up to the provider's create instance method.
Without this patch the snmp_community provider does not have the ability to destroy resources on the target device, nor the ability to manage a specific property of an existing resource. This patch addresses the problem by implementing the provider flush method. The behavior of all the property setter methods is to set a key for the property in the @property_flush instance variable. The flush method merges the @property_flush instance variable on top of the @property_hash variable in order to preserve existing properties that are not being managed by the applied catalog.
Without this patch the snmp_notification type does not obtain all
existing snmp notification resources on the target device. This is a
problem because we need all of the existing instances prior to managing
the resource specified in the Puppet configuration catalog.
This patch addresses the problem by implementing the provider instances
class method. This method parses the output of the `show snmp trap`
command and returns a provider instance for each notification type. For
example:
snmp_notification { 'ospf nbr-state-change':
enable => 'true',
}
snmp_notification { 'pim neighbor-loss':
enable => 'false',
}
snmp_notification { 'snmp authentication':
enable => 'true',
}
snmp_notification { 'snmp link-down':
enable => 'true',
}
snmp_notification { 'snmp link-up':
enable => 'true',
}
Without this patch the provider cannot manage the state of the snmp notification resource on the target device. This patch addresses the problem by implementing the flush provider method which maps the enable property along with the name to the `snmp-server enable traps` EOS API command.
jeffmccune
pushed a commit
that referenced
this pull request
Nov 3, 2014
(ARISTA-23) Implement snmp_notification provider
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These two patches implement the provider instances and flush methods to manage
SNMP notification traps on the target device. The provider roughly maps to the
snmp-server enable trapscommand.