Showing results for 
Search instead for 
Did you mean: 

Cisco Employee

NSO GUI requirements


Hi there,



I keep seeing questions/requests around the NSO GUI. We have a very small GUI development team, and I would like to solicit input from this forum on how we can get maximum impact.



How do we think GUI impacts our sales? Our theory so far has been that our users don’t and wouldn’t use an NSO GUI for order entry. Can we validate that theory? Do we know of any NSO customers that don’t use some other system in front of NSO? How would such a customer be characterised? Certain size? Certain segment?



We could address our effort towards a number of audiences, e.g.



    1. Pre-sales, towards a buying audience:

      1. Cleaning up the current auto-generated GUI in order to enable demo/POC service models to be driven from a GUI (current top candidate)

      1. Example external GUI portal to enable the demo/POC developer to create a simple custom GUI for order entry (the problem with the current virtual MPLS demo is that the demo GUI is not an example of how we would advise our customers to create a GUI)

    1. Post-sales, for IT, for maintaining the NSO system

      1. Improving the admin GUI – how? Cleaning up GUI for users, credentials (internal/external), devices, device groups

    1. Post-sales, for operations

      1. Device management – device templates, policies, compliance?

      1. Cleaning up current auto-generated GUI? Unlikely that this would be used in operations

      1. Example external GUI portal? More likely candidate IMHO


IMHO, I don’t think a self-service portal should interface with NSO – this scenario would require order management functionality, but I’d be interested in your views on this.



Anything else?






Cisco Employee


Hi KJ,



We have a small SP in Israel that purchased NSO last year and, at least for the time being, intends to use it directly.


The current GUI cannot really be used, as some basic functionality is not really working (at least the last time I checked).



For example, the topic that was discussed few times here before: If you have a yang model with leafrefs to device names and ports on these devices – the list of interfaces according to the selected device is not being populated, so the user cannot see a drop-down list in a manner similar to ncs_cli.



I think similar issues exist with leaves/containers conditioned by when-statements, but am not sure about it.



Anyway, I think that some small customers might want to use the GUI – it doesn’t have to be pretty, but I think they might want it to be able to provide the basic stuff that ncs_cli provides for service activation.


I also think that during pre-sale / poc we should be cautious not to raise false hope that the provided gui can provide service-activation capabilities similar to the ones that the cli provides.







Cisco Employee


Telstra Ops and Cisco IT has requested a useful NSO Web UI for templates


*Real* users, hurray, not “just” Cisco sales



Daniels team put something together to get them through a POC:


Cisco Employee


Hi KJ,



In my opinion, the best return for investment would be to improve the auto-generated GUI. This will immensely help pre-sales. With pre-sales, there is a certain audience type that only see the value-proposition if it is communicated to them via some decent GUI.



It can also help post-sales admin/operators for small and/or initial installations - at times customers (network engineers) are looking for an out-of-box portal. That is after they finish building the service-packages, they would like to try it out in production on a small part of their network. Building just the service-packages is a steep learning curve for them and then having  to build a useable portal on top can be a big turn-off. Once they have successfully done initial deployment and want to expand, the organisation would be more willing to invest in a full blown portal solution.



I’m not convinced that “Example external GUI portal” would be of much value. There is a whole web-app industry out there, no point re-inventing the wheel.



Some of the line-items I’d like to be explored for improvement to the auto-generated GUI:


  1. The dynamic rendering of leafrefs based on user selection that Yftach points out below.
  2. Choice in terms of the landing page. For example, I’d like to land on a page with the services deployed in NSO.
  3. Ability to hide/unhide fields/tabs. At the moment actions/oper-data etc. all get rendered. Not very welcoming.
  4. Would be nice to be able to change style (CSS), placement of things across tabs, re-skinning etc.
  5. Ability to make the above customisation without having to do JavaScript. Perhaps as metadata/annotations in the service yang model itself.
  6. Some generic Graphing module which can be used to render things like topology, etc. Be able to click/drag and run “actions” on nodes.
  7. I’m sure I can come up with more items J






Cisco Employee





Agree with Bilal on auto-generated GUI being most impactful. Additional points to add:


    • For customers who are building a greenfield automation environment, they want to use some out-of-the-box GUI for an initial period while there is another team or project to build their GUI portal or other northbound system to consume the REST/API

    • Engineers want the auto-generated GUI to quickly check/validate and test their models

    • This is my opinion, and happy to be corrected - I feel a lot of middle management (those people with funding) feel better perceived value if they can see the outcomes through the auto-generated GUI than CLI-based interaction, even though this will be of interim use. In most cases, I feel Cisco’s scope might not include the northbound work order management or user portals as those always seem to cark us up.



If by “example external GUI portal” you mean a portal that is manually build to demonstrate one specific use case, this is certainly very useful to demonstrate that particular use case, but it might need to be modified to demonstrate other use cases.



Hope this helps.





Khay Kid


Cisco Employee


Hi Everyone,



I’ve been contemplating my response today. But no need as the ones below clearly capture our Advanced Services Mobility needs as well;



Working Gui to do POC, testing of new developed services, introduction of NSO to the customers without need for custom NB portal.





Cisco Employee





+1 for using GUI for POC’s and demo’s to customers who don’t have a NB portal.


It would be nice to have a stable GUI with enhanced look & feel and proper error handling with user-friendly messages.


Cisco Employee


I think it depends what you’re trying to sell. If you’re trying to sell NSO as a platform, then the generic operationally-focused GUI is fine. It’s a UI for NSO.



However, if you’re trying to sell (i.e. demonstrate or PoC) a very specific use case, then I think that a very lean and tailored UI is required. This will allow the customer to clearly see how NSO enables them to solve the specific operational issues or business outcomes they desire. Disclaimer: this is the approach that my team has taken in the construction of a PoC Web UI for NSO in APJ, so I am biased.



We have created a small, easily customised, Web UI framework written 100% in Java. All the HTML and JavaScript is generated server-side, so only the Java code needs to be changed in order to create a new use case. A new use case can be turned around in a couple of days. We have use cases for Layer 3 VPN, Layer 2 VPN, VNF management, and Zero Touch Provisioning for NSO with Autonomic Networking. The code is openly available for internal use and we encourage people to pull it and customise it for their own use:



Our approach was presented at the previous SEVT (at the 1:21 mark):



A video demonstration of our Layer 3 VPN use case portal for NSO:



We are currently working as part of the global Agile Development Team in GSP to create a common portal framework for GSP pre-sales PoC’s and demonstrations.



  .:|:.:|:.  Richard Wade





Thanks for the link and great work on a portal framework.



One important question: Why are you using the REST API and not JSON-RPC or NETCONF?  I worked with the EMEA innovation edge on a couple of project where we used NETCONF in Java (Tail-f open-sourced the client code) and it works great. With NETCONF you win transaction support and notifications. Notifications are a requirement when you use reactive fastmap.





Cisco Employee