issues raised by iX team

[vnitinv]

Salt release

• Unknown when the Junos updates will be integrated into the Salt software
• Juniper Github code does not include all the final updates – Nitin to notify iX when the changes are merged into the Juniper code and it can be used for testing

junos.install_config / junos.load

• functions do not recognize the .json file extension for config/template files
• code docs for both state functions list name in the parameter list but use path in the examples – needs to be corrected to path
• junos.load code docs have all merge, overwrite, replace, and update as False – to update merge to True, because it is the default
• install_config generates an error when trying to update the ephemeral database, because the code tries to do a diff with the previous version, which is not supported – will look into fixing this (similar to mode dynamic); leaving in the documentation for the ephemeral database, because it will likely be supported upon release

junos.install_os

• Code does not yet support installing images when you have separate master/proxy minion servers.
• All images file must reside on the Salt master, but there was a discussion that copying the file from master>proxy>junos device would take too much time. Advise if this changes the docs.
• VM Host upgrade – unclear how to reboot in this scenario (Junos PyEZ uses reboot(vmhost=True); what should the Salt doc example have?
• ISSU reboot – does adding reboot param to install_os correctly reboot the old master and only that RE? The backup RE should be rebooted during the install, so we only want to reboot the connected RE at the end I think, but there is no way to specify say all_RE=False in this case. So what’s the proper way to do this?

junos.get_table

• If the user omits the path param, the code should look for the table in both the Junos PyEZ op and command directories by default; currently it only checks the op directory
• The state function’s param list and example use “file” instead of “table_file”. Per the meeting, this should be table_file.
• For op tables that execute RPCs, how do you override the default arguments in the “args” section of the table? Although template_args is technically for command tables, it also seems to work for overriding the default values in op tables – can we document doing this, or should we have a separate “args” param? xxx to check on this.

timeout vs dev_timeout

• All execution and state functions will use dev_timeout, not timeout;
• check whether there is any difference with timeout in install_os function