Skip to content
Jason Edelman edited this page Apr 28, 2014 · 3 revisions

What is CPAL all about?

First and foremost, we must understand that CPAL is NOT an application. This was one of the key drivers on why CPAL was started. CPAL is a library ( or collection of libraries ) to make it easier for a) building multi-vendor network applications and b) using the Python Shell as the CLI.

In the original demo, there was a demo of "tables" to quickly build tables of particular data pulled from device "facts." Even this, is not technically part of CPAL. Is it a tool built off CPAL data used and ultimately pulled from a different library.

It is important to point this out as there are many great suggestions of HOW to use CPAL. These suggestions do NOT have to be part of CPAL. Once they are fully baked, there is no reason they can't be part of CPAL tools/widgets, but these are not a core driver/mission of CPAL.

Architectural Principles

  1. Each vendor module shall be able to evolve independently
  2. Each vendor module shall abide by set guidelines on data structure definition and format, e.g. routing table must be stored as a dictionary and MAC address must be in format XX:YY.
  3. It is perfectly acceptable to have a specific vendor's module incorporate a "new feature" or the pulling of a new type of data that hasn't been a directive of CPAL. Should it get traction, it can be added to the other modules.
  4. Each API module must support "facts"
  5. Facts MUST be consistent across ALL devices

Questions

1a. There will be other "facts" about particular types of devices (LB, router, switch, etc.) that should be stored in a new "type" dictionary. "Type" to define it can be manually set. Need to explore this.

1b. Rather than do a dictionary per device type, we can create a dictionary per OSI layer to make it more cross functional. Example: layer2={vlans: all vlans, vlan names, etc., vtp: 'enabled/disabled', 'vtp_domain':'test'} This actually would be a dictionary of dictionaries too, but think it would streamline things. Dict of Dict b/c even with VTP, there should first be a VTP dictionary stores domain, password, status, mode, etc.

  1. Decide if CPAL should be used to make changes TODAY, or if the focus should be on extracting data

API Types Currently Being Worked On

  1. Cisco onePK
  2. Arista eAPI
  3. F5 SOAP API

Device Types to incorporate

  1. Legacy with Paramiko
  2. Open vSwitch
  3. Juniper
  4. VMware vSwitch (via vCenter APIs)