design out support for boards that auto-enumerate devices

the current configuration design is to have a plugin specify the prototypes for all supported devices of a given plugin, then have the actual device instances be configured separately. the idea would be that a user can write some device configurations, mount that into the container (or otherwise make it available to the plugin) and then the plugin will know all of the devices that are supported.

in synse 1.X, IPMI was configured by specifying the BMC (ip/port/user/pass) and then getting the sensors (devices) off of the BMC SDR. This would be a case where the device information can be enumerated by the board, so the user doesn't actually need to configure devices (just the BMC boards).

This isn't supported here yet, so I'll need to think through how we can specify board-enumerated devices via the configuration, and how to allow the SDK to support the plugin-specific implementation for that enumeration.

I think I have a notion of what should make sense here.

I think this will require changes to plugin.yml, config.go, utils.go, server.go, interface.go.

I've done a little playing around/experimentation with this, so I think the below should work. I will consider this comment sufficient for the design of auto-enumeration. Really, not much has to be done by the SDK for enumeration - its mostly just giving an easy way for the plugin author to specify auto-enumeration for their plugin.

plugin.yml

I think it makes the most sense to have the plugin auto-enumeration defined here. I played around with the thought of including it in the device instance configuration, but in the end a board-level configuration doesn't belong in a device-level config. I didn't want to force it in there because thats how configurations get big and clunky.

plugin.yml makes sense, though. it is the configuration for that instance of the plugin. I think adding an auto_enumerate field to the config (open to better naming suggestions) would allow plugins to specify whatever data they need to auto configure. additionally, other changes can be made to the plugin config to make it better organized/easier to read/maintain. a thought of what it could look like all together:

make: plugin
version: 0.1.3
debug: true

settings:
  loop_delay: 250
  read:
    buffer_size: 100
  write:
    buffer_size: 100
    per_loop: 5
  transaction:
    ttl: 600

auto_enumerate:
  - ip: 10.10.1.20
    port: 623
    user: admin
    pass: admin
  - ip: 10.10.1.22
    port: 623
    user: admin
    pass: admin

the other changes to config organization, etc. would be separate issues, but I think moving towards something like this does make it easier to read/maintain and allows some flexibility into the future.

config.go

Obviously, if the configuration scheme changes, the thing that reads in the configurations changes. The changes I anticipate here would pretty much just be for scheme parity.

server.go

When a new plugin server is created, the plugin handler and device handlers are registered to it, then it reads in the device configs and generates the device models from that config. here, there should also be some checks for the auto_enumerate functionality and, if it exists, devices models should be generated from the auto_enumeration.

utils.go

most of the functionality of the actual device model generation from auto-enumeration mentioned in the server.go section would probably live here, along with any other helpers that could be needed.

interface.go

the DeviceHandler interface would need a new function that allows the plugin to specify the behavior for auto enumeration. obviously, how something is auto-enumerated is plugin dependent, so the plugin needs to provide that functionality.

vapor-ware / synse-sdk