One of many joys of being a product manager for a true platform product (NSO that is) that you get to find out the many cool and inspiring things people do with it that you may not have thought of in the first place. NSO is to some extent that magical fishing rod for network automation, and our users go fish in a very wide variety of lakes hunting for pretty exotic fish. And I'm always delighted to see their catches on display. Add to that the fact that people who fish with NSO are generally very passionate fisherpeople and it makes for an interesting day. In order to keep this (already somewhat stretched) fishing parable alive, I've also found that many of the fisherpeople (network automation anglers?) are very happy and proud to show off their catch during public events, including the sharing of some spectacular fishing stories. So in order to stay up with the latest and greatest in catches and stories I headed over to the Fishco^H^H^H^H^H^H Cisco Live US 2019 sessions catalog and did a free form search on 'NSO' . This time around I found 27(!) different sessions that had "NSO" in either the topic name or in the abstract description. And that includes my own two sessions . I can honestly say that I only knew of about half of the people and topics beforehand and some of the ones that I had not seen before have topic names that makes me extremely curious and interested to know more. The depth and breadth of the topics and the role descriptions of the presenters is truly great, and the wealth of insight and experience in using NSO in some of thew world's most challenging waters truly humbles me. As a cisco employee we get dispreferential (!) access to sessions that are fully booked, so I don't have too much hope in getting comfortable access to all the sessions. But for those of you going to Cisco Live US this year, and are planning to attend any of the NSO sessions. Look for a weathered fisherman against the back wall as that might just be me trying to learn more. And if you feel like it, come up and share any kind of fishing story you may have, or ask me for one. I love this stuff.
... View more
Spring is in the air, which in Swedish terms means that temperatures are (mostly) above freezing, and we get more than 3-4 hours of sunlight per 24-hour cycle. This also traditionally (3 years is a tradition, no?) means that we are heads-down planning our yearly Developer Days event that will take place 18 to 20 June this year in Stockholm, Sweden as per the usual.
The main feedback we received last year was along three lines:
MORE - as in time together during the event
DEEPER - as in the nature of the topics during the longer event
MEATBALLS - as we forgot, for some reason, to serve that last year
We have made the event longer this year - three days with an extra intro day for beginners, deeper - as in we have an awesome set of both external and Cisco-internal speakers going deep on many topics) and we will do our very best to serve Swedish Meatballs.
NSO is designed on a set of core ideas and principles to solve some of what we believe to be the hardest problems in robust and realistic (i.e. usable on real networks) network automation and abstraction. Most (if not all) of these principles are very much generally applicable in todays network, and we will dive deeper also in this dimension of the solution.
We are lining up some very interesting speakers. We have a mix of people using NSO to manage some very large networks, engineers from NSO core development team, and engineers from our services-side that have worked together with customers to develop with, and deploy NSO across service providers and enterprises.
I myself have been given a nice slot during the Thursday and am hard at work putting together content for you to wake up over. I have some strong opinions, and I know that an audience may need some waking up exercises on the last day of a content-ehavy event (and after "midsummer" *hinthint* ). My aim is to make it a great opportunity for sharing my view on the future of the domain NSO is acting in, and certainly (and interactively) get feedback on it.
The feedback from last year also called for more face time with both users, but also with engineers and product managers from the NSO team. We have made sure that we have ample time and space set aside for deeper and more specific conversations on the needs and feedback from the user community.
We have also worked hard to make sure we stay ahead of ourselves when it comes to our social event. The dinner by the Vasa Ship last year got rave reviews. So we really had to dig deep this year. I can tell you that the theme this year will be Swedish Midsummer which conveniently actually happens the weekend after the event for people who are able to stay behind.
Ticket sales are now open, so head over to the registration page and make sure to secure a seat and I will see you in Stockholm in June!
... View more
We are packing our tote-bags with NSO and Ansible modules to go to Ansiblefest 2018 in Austin, Texas on Oct 2-3. This is a continuation of (and a step up from) our presence and presentation at Ansiblefest last year when we launched our NSO modules.
What's new this year is that I will be sharing the presentation stage (2:30-3:15PM on Wed, Oct 3 thanks for asking) with Kevin Corbin who is a solution architect in the enterprise networking team. Kevin will provide the very much needed experience-based framing on how NSO and Ansible is better together for the enterprise networking crowd. We have done lots of further development of on the modules and hammered extensively on them to make sure they are rock solid and easy to use.
Kevin will work through a brand new spanking demo taking the work we did last year but expanding into the new modules, and introducing some services into NSO. It will be great. We will post all work on our NSO Developer github after the event.
If you are going to Austin, come by our sponsor table and say hi!
... View more
Final (and brief) update. The first three modules are now all in ansible:devel and ready for Ansible 2.5. We may be able to sneak in two more modules (show and query) as well. cnasten is working on it.
... View more
I'm happy to say that our first pull request has been accepted into ansible:devel in preparation for inclusion into ansible 2.5. The commit content is available here. Next up is to open pull requests for the other two modules (nso_verify and nso_action). Stay tuned!
... View more
Three weeks ago we set up shop at SDN and NFV World Congress 2017 in the Hague, Netherlands. This is a great event, with many visitors from the service provider community with a special interest around SDN and NFV. We try to bring new and interesting content to this event, so we decided to team up with our colleagues over at the Cloud Center team. This year we designed and built a demo with the Cloud Center management platform deploying a two-tier application across Amazon AWS and a local OpenStack instance, with NSO building a secure network between them based on cloud-hosted Cisco CSR 1000v. It was very well received and kept the demo-people in the booth busy throughout the event. The following is the demo that we used for the show: Video Link : 16669 Please reach out to me if you have any further questions or feedback.
... View more
A couple of weeks I presented work we have done on NSO and Ansible integration to a great audience at Ansiblefest 2017 in San Francisco. The videos are available here. The presentation consisted of an introduction to NSO, and introduced three new Ansible modules for interacting with NSO. This was our first time presenting the solution to this audience and based on the healthy-sized number of people that wanted to chat after the presentation (which is a great way of measuring the impact of your content) it seems like it went well. To me, this validates our understanding that giving software tools like Ansible access to managing multi-vendor hybrid networks is the way to go about opening up for radical change in the industry. If nothing else, I believe by giving Ansible-users access to the network through a database-like API, and thereby making it significantly more manageable entity, we will see lots of interesting outcomes over time. We had a couple of ideas that we wanted to include in the design of the modules, including: Normalize the access to the configuration across vendors - use YAML in playbooks for all data encoding Reduce the amount of configuration changes in the network to the bare minimum - only change what you intend to do and avoid side-effects Provide a full create-read-update-delete interface to avoid exploding the number of vendor-specific modules - modules should express operations on data, not protocol details So, we built three modules to allow ansible to access data in NSO, one for each type of operation you are likely to perform on configuration and operational data: nso_configure - allows for updating (creating, changing, deleting) configuration data nso_verify - allows for verifying configuration and/or operational data is the same as expected nso_action - allows for triggering actions, i.e. operations with side-effects like 'reboot' or 'ping' The key here is that these three modules act on a common set of data, namely the data that resides in NSO according to the YANG modules loaded into the system. Think of NSO as exposing a large tree-representation of all your configuration and operational data, across all your network devices and services under management. The modules then allow you to operate on that data with NSO taking care of the details of robustly getting and setting configuration and operational data on devices and in services in a distributed and transaction-safe manner. By doing this we have removed: vendor-specific modules and proprietary encoding opaque configuration blobs that unnecessarily upsets your network separate modules for all activities you are allowed to do on the device And as an added bonus, we have also made sure that there is consistent roundtripping of data between NSO and playbooks. This means that you can reliably fetch configuration and operational data from NSO using the NSO RESTCONF interface or CLI, translate the resulting JSON to YAML that can be included (or simply pasted into) NSO module tasks. This literally removes (or radically reduces) the need for manual work when creating module content. The example I used during the presentation used curl(1) to fetch the running configuration of a device called jnpr0 and convert from the NSO RESTCONF interface JSON output and convert the response into YAML using the following command: $ curl -H "Accept: application/yang-data+json" http://localhost:8080/restconf/data/devices/device/jnpr0/config | ../json2yaml.py The YAML output can then be used in e.g. the nso_verify module to verify that the configuration stays the same. As an obvious next step for the more ansible-savvy; you can now apply a handler to the verify-task and on change, call an nso_config task with the content to revert back to the intended configuration. We are currently in process of upstreaming the modules into ansible core, you can track the progress of the pull request here.The demo files that I used during the presentation and referenced above is available from our developer hub github here. Feel free to reach out directly to me with any feedback or questions.
... View more
Scott, Very cool, this is exactly what I was looking for. Would you be interested in contributing some of what you have to a devnet github repo and see if we can build a reusable, shareable set?
... View more
I believe I have heard mentions of using Ansible to manage the NSO development and runtime environments, and am interested to capture any learnings from that. This would include tasks like installing and upgrading of the NSO runtime environment and packages, and perhaps even using Ansible to manage the lifecycle of clusters or LSO deployments across servers.
... View more
Just a heads-up for the YANG-inclined. We are just about to go through the last steps of publishing an IETF information RFC on the following topic (from the draft):
This document describes a set of concepts and associated terms to support consistent classification of YANG modules.
What is likely to be the final draft version before publishing is available here: draft-ietf-netmod-yang-model-classification-06 - YANG Module Classification. Feel free to discuss in groups
... View more