You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An error will only get returned if there's an issue with the SSH session or if the context has timed out. The returned string is just a concatenation of the output from the device during the configuration option. As mentioned in the intro post for Netrasp, this isn't ideal as configuration errors from the device more or less get ignored.
Netrasp should inspect the output from the network devices to determine the input is valid. What Netrasp does when an error occurs could be different for various platforms. For Cisco IOS, it could be that Netrasp stops applying configuration as soon as the output indicates config issues. Here it could be helpful for users if the return data contained a slice with used commands and the output from each, potentially making it easier to revert a bad change.
Things can work differently with other platforms that support staged configurations where the configurations are entered into a device and then applied with a commit command. For SROS, Junos, and IOS XR, it would make more sense to abort the configuration change as soon as an error in the config commands gets observed. For these platforms, an error could also occur after the commit command gets entered. When this happens, it should be clear for a user what caused the issue.
A better signature could be: Configure(context.Context, []string) (ConfigResult, error)
ConfigResult would be a struct that can contain a slice of the applied configuration commands and output. It should also include output from the commit if applicable.
Error types would be configuration errors, along with commit errors (such as trying to apply a policy that doesn't exist, etc.)
Other thoughts for the Configuration method:
If a Configuration command gets aborted due to Context timeout, the actual device context will remain in an active configuration operation. The end-user would be responsible for aborting that configuration and exiting out to a root level (i.e., enable mode on IOS)
Some platforms could make sense to allow for options to Configure, such as commit-confirmed, etc.
The text was updated successfully, but these errors were encountered:
This PR modified the method signature for Configure as described in #18.
It doesn't cover all features described in that issue. As it's a
breaking change for the early API it would be good to merge it sooner
rather than later and add to it once it's in place.
This PR modified the method signature for Configure as described in #18.
It doesn't cover all features described in that issue. As it's a
breaking change for the early API it would be good to merge it sooner
rather than later and add to it once it's in place.
This PR modified the method signature for Configure as described in #18.
It doesn't cover all features described in that issue. As it's a
breaking change for the early API it would be good to merge it sooner
rather than later and add to it once it's in place.
The Configure method currently has this signature:
Configure(context.Context, []string) (string, error)
An error will only get returned if there's an issue with the SSH session or if the context has timed out. The returned string is just a concatenation of the output from the device during the configuration option. As mentioned in the intro post for Netrasp, this isn't ideal as configuration errors from the device more or less get ignored.
Netrasp should inspect the output from the network devices to determine the input is valid. What Netrasp does when an error occurs could be different for various platforms. For Cisco IOS, it could be that Netrasp stops applying configuration as soon as the output indicates config issues. Here it could be helpful for users if the return data contained a slice with used commands and the output from each, potentially making it easier to revert a bad change.
Things can work differently with other platforms that support staged configurations where the configurations are entered into a device and then applied with a commit command. For SROS, Junos, and IOS XR, it would make more sense to abort the configuration change as soon as an error in the config commands gets observed. For these platforms, an error could also occur after the commit command gets entered. When this happens, it should be clear for a user what caused the issue.
A better signature could be:
Configure(context.Context, []string) (ConfigResult, error)
ConfigResult would be a struct that can contain a slice of the applied configuration commands and output. It should also include output from the commit if applicable.
Error types would be configuration errors, along with commit errors (such as trying to apply a policy that doesn't exist, etc.)
Other thoughts for the Configuration method:
The text was updated successfully, but these errors were encountered: