Implemented top-level Interface resource object.

- Addresses are assigned to Interfaces by way of Assignment objects,
  which are used to enforce relationship-level constraints on the
  assignment of Network objects to Device Interfaces.
- A Device can zero or more Interfaces; an Interface can have multiple
  addresses, and addresses are 'assigned' to Interfaces
- Networks are derived as the parent networks of the addresses for each
  interface.
- Moved hard-coded variable data in models.py into module-global
  constants.
- Renamed all model "choices" lists to end in "_CHOICES"
- New requirements: django-macaddress v1.3.2, Django v1.8.4
- Updated README.md to include IRC mention.
- All constants moved from `nsot.constants` to `nsot.conf.settings` and
  `nsot.constants` has been eliminiated. (fix #87)
- All data validators have been moved to `nsot.validators` and added new
  validators for cidr and host addresses.
- Moved `.to_representation()` methods on all 'resource' serializers to
  the top-level `nsot.api.serializers.NsotSerializer`
- Fixed a crash when creating `Network` objects without the CIDR being
  unicode.
- Fixed a bug when looking up a single object in API without providing
  site_pk
- Moved IP_VERSIONS and HOST_PREFIXES into settings.py
- IP assignments must now be unique to a device/interface tuple.
- Addresses can now be explicitly assigned to an interface, or
  overwritten
- Added a new `nsot.serializers.JSONListField` type to serialize JSON
  <-> Python lists
- Added util for deriving attributes from custom model fields that
  required custom serializer fields.
- Added `tests.api_tests.util.filter_interfaces` for simplifying
  `Interface` testing.
- Added 'ip_version' as a filter field for `Network` API lookups.

.gitignore

@@ -3,6 +3,7 @@ staticfiles
 
 *.sqlite
 *.sqlite-journal
+*.sqlite3
 
 # Bower Components
 _bc

README.md

@@ -5,18 +5,19 @@
 
 ## Warning
 
-This project is still very much in flux and likely to have database changes without
-migration support for the time being. Also some documentation may describe steps not yet possible.
+This project is stable and fully unit-tested, however as it is pre-1.0 it is
+still very much in flux and likely to have backwards-incompatible API changes
+for the time being. Also some documentation may describe steps not yet
+possible, or in some cases possible steps may not be fully documented. 
 
-### Description
+## Description
 
 NSoT is a Network Source of Truth API and FE for managing Network Assets.
 
-Currently only IP Address Management is on the road-map but it will evolve
-into more over time.
+Currently only IP Address Management is on the road-map but it will evolve into
+more over time.
 
-
-### Installation
+## Installation
 
 New versions will be updated to PyPI pretty regularly so it should be as easy
 as:
@@ -25,24 +26,25 @@ as:
 $ pip install nsot
 ```
 
-### Documentation
+## Documentation
 
 The latest documentation will always be available at http://nsot.readthedocs.org/en/latest/
 
-### Development
+## Development
 
-Note: You'll need to have a reasonably recent version of [npm](https://github.com/npm/npm) to build
-frontend dependencies. Minimum Version tested is `1.3.24`
+Note: You'll need to have a reasonably recent version of
+[npm](https://github.com/npm/npm) to build frontend dependencies. Minimum
+Version tested is `1.3.24`
 
-I suggest setting up your test environment in a virtual environment. If you use
-virtualenvwrapper you can just do
+We suggest setting up your test environment in a virtual environment. If you
+use virtualenvwrapper you can just do:
 
 ```bash
 $ mkvirtualenv nsot
 ```
 
-After that, clone the repo into whichever directory you use for development
-and install the dependencies.
+After that, clone the repo into whichever directory you use for development and
+install the dependencies.
 
 ```bash
 $ git clone [email protected]:dropbox/nsot.git
@@ -51,18 +53,19 @@ $ pip install -r requirements-dev.txt
 $ python setup.py develop
 ```
 #### Running Tests
+
 All tests will automatically be run on Travis CI when pull requests are sent.
 However, it's beneficial to run the tests often during development.
 
 ```bash
 py.test -v tests/
 ```
 
-#### Running a Test instance
+### Running a Test instance
 
-NSoT runs behind a reverse proxy that handles Authentication and so expects
-a valid, authenticated, user account. I've included a test proxy for running
-on development instances.
+NSoT runs behind a reverse proxy that handles Authentication and so expects a
+valid, authenticated, user account. We've included a test proxy for running on
+development instances.
 
 ```bash
 
@@ -80,7 +83,7 @@ nsot-server start
 
 ```
 
-#### Working with migrations
+### Working with migrations
 
 If you make any changes to the models you'll want to generate a new migration.
 We use Django's built-in support for migrations underneath, so for general
@@ -101,11 +104,11 @@ nsot-server migrate
 
 ```
 
-#### Working with docs
+### Working with docs
 
-Documentation is done with Sphinx. If you just want to build and view the docs you
-cd into the `docs` directory and run `make html`. Then point your browser to
-`docs/\_build/html/index.html` on your local filesystem.
+Documentation is done with Sphinx. If you just want to build and view the docs
+you cd into the `docs` directory and run `make html`. Then point your browser
+to `docs/\_build/html/index.html` on your local filesystem.
 
 If you're actively modifying the docs it's useful to run the autobuild server like
 so:
@@ -114,19 +117,20 @@ so:
 sphinx-autobuild docs docs/_build/html/
 ```
 
-This will start a server listening on a port that you can browse to and will
-be automatically reloaded when you change any rst files. One downside of this
+This will start a server listening on a port that you can browse to and will be
+automatically reloaded when you change any rst files. One downside of this
 approach is that is doesn't refresh when docstrings are modified.
 
-#### Frontend development
+### Frontend development
 
-We use a combination of npm, bower, and gulp to do frontend development. npm is used
-to manage our build dependencies, bower to manage our web dependencies, and gulp
-for building/linting/testing/etc.
+We use a combination of npm, bower, and gulp to do frontend development. npm is
+used to manage our build dependencies, bower to manage our web dependencies,
+and gulp for building/linting/testing/etc.
 
-`setup.py develop` will install and build all frontend components so for the most part
-you shouldn't need to care about these details though if you want to add new build
-dependencies, for example gulp-concat, you would run the followiing:
+`setup.py develop` will install and build all frontend components so for the
+most part you shouldn't need to care about these details though if you want to
+add new build dependencies, for example gulp-concat, you would run the
+followiing:
 
 ```bash
 # Install gulp-concat, updating package.json with a new devDependency
@@ -144,10 +148,16 @@ Adding new web dependencies are done through bower
 bower install lodash --save
 ```
 
-Unfortunately bower doesn't have a shrinkwrap/freeze feature so you'll want to update
-the version string to make the version explicit for repeatable builds.
+Unfortunately bower doesn't have a shrinkwrap/freeze feature so you'll want to
+update the version string to make the version explicit for repeatable builds.
+
+We make use of bower's "main file" concept to distribute only "main" files.
+Most packages don't consider consider the minified versions of their project to
+be their main files so you'll likely also need to update the `overrides`
+section of bower.json with which files to distribute.
+
+## Support
 
-We make use of bower's "main file" concept to distribute only "main" files. Most packages
-don't consider consider the minified versions of their project to be their main files so
-you'll likely also need to update the `overrides` section of bower.json with which files
-to distribute.
+For the time being the best way to get support, provide feedback, ask
+questions, or to just talk shop is to find us on IRC at `#nsot` on Freenode
+(irc://irc.freenode.net/nsot).

iftypes.txt

@@ -0,0 +1,34 @@
+Distinct types
+
+mysql> select if_type, count(*) as num from ports group by if_type;
++---------+--------+
+| if_type | num    |
++---------+--------+
+|       1 |   4482 |
+|       6 | 178033 |
+|      24 |   2031 |
+|      53 |  20402 |
+|     131 |    875 |
+|     135 |     17 |
+|     136 |   1590 |
+|     150 |    175 |
+|     161 |   3918 |
++---------+--------+
+9 rows in set (0.15 sec)
+
+Type mappings
+
+These are mappings to the formal integer types from SNMP IF-MIB::ifType. The
+types listed here are the most commonly found in the wild.
+
+Ref: https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib
+
+other(1),             -- none of the following
+ethernetCsmacd(6),    -- for all ethernet-like interfaces,
+                      -- regardless of speed, as per RFC3635
+softwareLoopback(24),
+tunnel (131),         -- Encapsulation interface
+l2vlan (135),         -- Layer 2 Virtual LAN using 802.1Q
+l3ipvlan (136),       -- Layer 3 Virtual LAN using IP
+mplsTunnel (150),     -- MPLS Tunnel Virtual Interface
+ieee8023adLag (161),  -- IEEE 802.3ad Link Aggregate

nsot/admin.py

@@ -90,3 +90,12 @@ def get_cidr(self):
     fields = ('network_address', 'broadcast_address', 'prefix_length',
               'ip_version', 'is_ip', 'parent', 'site')
 admin.site.register(models.Network, NetworkAdmin)
+
+
+class InterfaceAdmin(PolymorphicChildModelAdmin):
+    base_model = models.Interface
+    list_display = ('name', 'parent', 'mac_address', 'device', 'type', 'speed')
+    list_filter = ('name', 'mac_address', 'device', 'type', 'speed')
+
+    fields = list_display
+admin.site.register(models.Interface, InterfaceAdmin)