User Tools

Site Tools


maintenance:releases:7.0.5_20181203
LDAP: couldn't connect to LDAP server

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
maintenance:releases:7.0.5_20181203 [2019/07/16 13:15] – ↷ Page moved from releases:7.0.5_20181203 to maintenance:releases:7.0.5_20181203 jboschmaintenance:releases:7.0.5_20181203 [2019/12/23 15:48] (current) yspeerte
Line 1: Line 1:
 +{{indexmenu_n>20181203}}
 +
 +===== NetYCE 7.0.5 Build_20181203 =====
 +===== Release notes =====
 +Date: 2018-12-03
 +
 +
 +\\ 
 +<WRAP widths 60% box safety>
 +==== Enhancement ====
 +</WRAP>
 +
 +=== CMDB objects ===
 +<WRAP indent>
 +In preparation for the all-new 'Basic Command Jobs' currently under development, several
 +reserved objects named 'CMDB' have been added to the NetYCE database. These basic command 
 +jobs will permit the creation of command-jobs for all devices present in the CMDB table. 
 +These basic jobs have full support for command and config parsing and have limited parameter 
 +substitution capabilities. 
 +
 +To support the use of basic templates and relations, the 'CMDB' objects for 'Client-type', 
 +'Region', 'Client', 'Site', and 'Service_class' have been added. These objects cannot 
 +be deleted since they are essential for the functioning these basic jobs. 
 +
 +For environments where these 'CMDB' objects are perceived as undesirable, they can easily 
 +be hidden by removing the 'CMDB' client-type from the NetYCE user-groups.\\
 +**Note:** Hidden from the BUILD -> MAIN only. The Objects are always seen under Operate -> CMDB
 +</WRAP>
 +
 +=== New Topo check report ===
 +<WRAP indent>
 +A specialized report has been added to the Operate - Reports menu: 'Topo check'. This allows the
 +modeler to report on all topology links where a mismatch exists between the assigned subnets 
 +at both ends. Depending on the design such a mismatch could be an issue or not.
 +
 +The output lists topos with mismatches only and is sorted by Client_type, Hostname, Link-type. 
 +Per topology link the missing subnet details are listed.
 +</WRAP>
 +
 +
 +\\ 
 +<WRAP widths 60% box safety>
 +==== Change ====
 +</WRAP>
 +
 +=== Command jobs ===
 +<WRAP indent>
 +The preparation and execution of command jobs was extensively modified with the 7.0.5
 +release. One of these changes involved generating the command job configurations 
 +at the time of execution instead of job submission time.
 +
 +The scenario command '**Cmd_exec**' was modified to generate the commands from the 'template'
 +that are the commands entered. It would use this <jobid>.cmd as template to generate the 
 +commands using the node specified in the '**-n**' option and then execute the result on the
 +same device. The '-f' option is used to name generated command file for reference purposes.
 +
 +The scenario line would then be similar to this:
 +<code>
 +-- example
 +<node> = NL-ACME-CPE
 +
 +Cmd_exec -n <node> -f <node>.cmd <verbose>
 +-- generates NL-ACME-CPE.cmd using NL-ACME-CPE data and executes it on NL-ACME-CPE
 +</code>
 +
 +However, this approach would prevent you from generating the commands from this 'template'
 +when the execution must be performed on a different node than the node (or context) these
 +commands were generated for. To resolve this issue, the option '**-o**' was added to the
 +Cmd_exec. The '-o <node>' (origin-node) specifies the node name whose context is used to
 +generate the commands from the command-job 'template'. These commands are then executed 
 +on the node specified with '-n' as usual. 
 +
 +When the -o is omitted, the '-n <node>' is providing the context from which the commands 
 +are generated. The Cmd_exec will NOT generate the named file if it already exists.
 +
 +<code>
 +-- examples
 +<node> = NL-ACME-CPE
 +<code_node> = NL-AMS-CR02
 +
 +Cmd_exec -o <node> -n NL-AMS-CR01 <verbose>
 +-- generates the file NL-ACME-CPE.cmd using NL-ACME-CPE data and executes it on NL-AMS-CR01
 +
 +Cmd_exec -o <node> -n <core_node> -f <core_node>.cmd <verbose>
 +-- generates the file NL-AMS-CR02.cmd using NL-ACME-CPE data and executes it on NL-AMS-CR02
 +</code>
 +
 +The change requires the engineer to explicitly define the context and the target nodes
 +instead of relying on a command file that was implicitly generated at job-submission time.
 +This approach also allows to re-use the command 'template' for multiple nodes within the
 +scenario. The context and target nodes can be switched as appropriate.
 +<code>
 +-- example
 +<node> = NL-ACME-CPE
 +<code_node1> = NL-AMS-CR01
 +<code_node2> = NL-AMS-CR02
 +
 +Cmd_exec -o <core_node1> -n <node> -f <node>_part1.cmd <verbose>
 +-- generates NL-ACME-CPE_part1.cmd using NL-AMS-CR01 data and executes it on NL-ACME-CPE
 +
 +Cmd_exec -o <code_node2> -n <node> -f <node>_part2.cmd <verbose>
 +-- generates NL-ACME-CPE_part2.cmd using NL-AMS-CR02 data and executes it on NL-ACME-CPE
 +</code>
 +</WRAP>
 +
 +=== Node port display order ===
 +<WRAP indent>
 +When viewing the ports of a node, the ports are virualized per slot in groups of ports per 
 +port-type (e.g. Fast_ethernet, Gigabit-ethernet, Loopback, Port_channel). The order of these
 +port-types was often inconvenient since it was more or less random.
 +
 +This behaviour is now changed and lists the port-types in a fixed order: Ethernet, Fast_ethernet,
 +Gigabit_ethernet, TenGigabit_ethernet, etc. The order is controlled using the internal Port_class 
 +table where also the port-type name is mapped to the port-class. If required, the order can be 
 +modified to customer taste.
 +</WRAP>
 +
 +=== Node port display truncated ===
 +<WRAP indent>
 +On nodes where the port-ids of a port-type exceed 150 will the clickable ports now be truncated.
 +This is most often the case for Loopback or Port_channel type ports, but the behaviour is general.
 +It will prevent extensive scrolling past unused port-id's and improves the rendering speed of 
 +the ports by the browser.
 +
 +When the list of ports for a port-type is truncated, it is indicated by a [=>] symbol indicating
 +the list continues but is not shown. The full list will be available using the grid at the top of 
 +the form.
 +</WRAP>
 +
 +
 +\\ 
 +<WRAP widths 60% box safety>
 +==== Fix ====
 +</WRAP>
 +
 +=== Scenario variable resolving ===
 +<WRAP indent>
 +With the redesigned command job and scenario handling of version 7.0.5 the variables handling
 +was modified. The command generator now has access to all scenario variables which in turn
 +extended to the relations.
 +
 +With this behaviour in place we believed the scenario would no longer require variable 
 +substitution from the node. This assumption proved incorrect. Although scenario facilities exist
 +to access relations for a node, existing scenarios in production were incompatible.
 +
 +As a result the original scenario behaviour has been re-implemented. At time of execution, 
 +the entire scenario is parsed for variables and relations from the <node> context and substituted.
 +This restores the functionality of the existing scenarios.
 +</WRAP>
 +
 +=== Node_log support ===
 +<WRAP indent>
 +The Vendor modules were for the 7.0.5 release updated to behave more consistently and allow better 
 +control over error conditions. This was partly realized by creating more common functions for
 +all vendors to use. Most of the existing functions were ported to these new vendor modules, but
 +not all. The function to store the results of 'show' commands proved to be amongst these, although
 +not intentionally.
 +
 +To correct this situation, the function has been re-implemented. CLI commands starting with vendor
 +specific key words like 'show' or 'display' are detected and their results stored in the YCE Node_log
 +table for later examination or reporting.
 +
 +  * the 'show'-type commands must be fully typed, abbreviations are not supported
 +  * the 'show'-type commands are executed as any other, only afterwards is the command evaluated as a storable result and saved in the database.
 +  * the 'show'-type commands are expected to be executed in the appropriate mode. The vendor module will not magically switch between enabled and disabled modes.
 +
 +Most vendors have the commands for 'show' or 'display' and 'ping', 'dir', 'do' recognized.
 +</WRAP>
 +
 +=== Duplicate node slots ===
 +<WRAP indent>
 +A bug where romoved nodes did not clean up their node-slots caused duplicate node-slots when these nodes
 +were re-created. Altough the problemof not removing the slots was fixed, the existing duplicates
 +would not be removed until a port was added or removed from the node.
 +
 +A patch will be executed when updating the NetYCE system to remove these duplicate slots.
 +</WRAP>
 +
 +=== Show command logging ===
 +<WRAP indent>
 +When executing cli jobs on a device, the job can contain 'show' commands. The results
 +of these commands are logged in the job log but were also stored in the NetYCE database
 +in the Node_logs table for reporting purposes.
 +
 +This functionality was not ported correctly to the various vendor modules when version 
 +7.0.5 was prelim released. However, a bug prevented the actual use of this restored function
 +which has now been fixed.
 +</WRAP>
 +
 +=== Command parsing ===
 +<WRAP indent>
 +Command parsing in job scenarios fails due to a misconfiguration in the state-machine
 +configuration of several vendors. The functionality has now been restored.
 +</WRAP>
 +
  
maintenance/releases/7.0.5_20181203.txt · Last modified: 2019/12/23 15:48 by yspeerte