-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(ARISTA-3) Add EOS port_channel provider #2
Merged
jeffmccune
merged 12 commits into
arista-eosplus:master
from
jeffmccune:ar3_port_channel
Nov 3, 2014
Merged
(ARISTA-3) Add EOS port_channel provider #2
jeffmccune
merged 12 commits into
arista-eosplus:master
from
jeffmccune:ar3_port_channel
Nov 3, 2014
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
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.
jeffmccune
pushed a commit
that referenced
this pull request
Nov 3, 2014
(ARISTA-3) Add EOS port_channel 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.
This series of patches adds all of the behavior for the port_channel type.