Make -s/--site-id actually work!

[coxley]

Very important ASAP fix.

It appears that my understanding of the API behavior regarding assigning site id was incorrect. Currently we are doing:

"networks": [
    {
      "is_ip": true,
      "network_address": "10.97.3.113",
      "site_id": 1,
      "state": "assigned",
      "prefix_length": 32,
      "attributes": {
        "desc": "wlp2s0 on coxley"
      }
    }
]

and regardless of the site_id value it'll get set to .pynsotrc default_site. I quickly tried instantiating the client with:

from pynsot.client import get_api_client

c = get_api_client(extra_args={'default_site': 2})

c.devices.get()

{u'data': {u'devices': [{u'attributes': {},
    u'hostname': u'coxley',
    u'id': 1,
    u'site_id': 1}],
  u'limit': None,
  u'offset': 0,
  u'total': 1},
 u'status': u'ok'}

and that obviously didn't work. May need to raise an issue upstream? Will try fiddling around first, but having to do:

c.site(2).devices.get()

would be annoying but working. (maybe?)

[coxley]

Update: This might be a red herring, but there's definitely a bug or two now.

Witnessing behavior where a REQUIRED_ATTRS attribute isn't being ensured, site_id isn't applied to resources when --noop is called, and perhaps pre-emptive "SUCCESS" logs are being printed out before anything has been don.

Will investigate harder soon. Itests will make this so much better!

[coxley]

Confirmed that something is wonky with logs compared to actuality.

Site selection does work but network resources can be claimed to be created when they aren't.

[coxley]

I take back my confirmation. There appears to be a couple bugs upstream in newer version of NSoT. The site functionality works so this issue should be closed.