search

nuvla / api-server

Nuvla API server packaged as a Docker container
https://sixsq.com
Apache License 2.0
5 stars 2 forks source link

draft new resource schema and workflow for NB peripherals #223

Closed cjdcordeiro closed 5 years ago

cjdcordeiro commented 5 years ago

This ticket is about planning for the new server resource which shall be associated with the NuvlaBox resource, and comprise all the peripherals on the NuvlaBox, which can then be mapped onto a Nuvla application

cjdcordeiro commented 5 years ago

Untitled

Untitled4

Untitled3

Untitled2

cjdcordeiro commented 5 years ago

Suggested names:

Schema

{
    identifier: str,           # (required) something like "046d:082d"
    name: str,                 # (common attr) something like "Logitech, Inc. HD Pro Webcam C920"
    parent: ref,               # (common) reference to the nuvlabox_resource
    available: boolean,  # (required) true/false
    host-device-path: str,      # (optional) something like "/dev/bus/usb/001/001", whenever we can get that
    interface: { USB | BLUETOOTH | GPIO | ... },     # (required) hardware interface the peripheral is using
    adapter: str              # (optional) doesn't really apply for peripherals, but more for embedded hardware sensors. Maybe we don't want to track those. If so, then just discard this attr
}
loomis commented 5 years ago

The first version looks good in general. Specific comments:

Presumably these resources will need to be versioned along with the other nuvlabox resources. A 'version' field will be required in that case.

The schema as it is provides very little opportunity for automated matching between applications and devices. Essentially the only fields with reliable values are interface/protocol and available. This isn't enough to distinguish between cameras, microphones, thermometers, etc. Is automated matching a goal, or will the matching always be manual?

cjdcordeiro commented 5 years ago

The first version looks good in general. Specific comments:

  • I'd prefer 'nuvlabox-peripheral' to keep all of the nuvlabox resources together.

👍

  • For the application specification of devices, either this should be constraints on specific fields of the nuvlabox-peripheral resource or a standard CIMI filter against those fields. Truly free text wouldn't be useful for matching or allocation of devices.

the thing is that when you are defining the application, you don't know yet which NuvlaBox you're going to deploy to so you can't match against any peripherals. And even if you'd match against existing peripherals, the actual field we want here is the host-device-path, which we might not always know.

  • I'd prefer 'protocol' over 'interface', as I find interface too general.

That was my first though but then, USB isn't a protocol for example. What all peripherals have in common is that they are all connected to the NuvlaBox via a hardware interface

  • I think that 'host-device-path' can probably just be simplified to device.

👍

  • Unless there's a concrete example for 'adapter', it would be better left out.

There are examples (ISA adapter, SMBus nForce2 adapter at 4d00, etc...https://wiki.archlinux.org/index.php/Lm_sensors). The thing is that these are all embedded sensors, and not really peripherals. Should we manage these as well? Or don't report them at all?

Presumably these resources will need to be versioned along with the other nuvlabox resources. A 'version' field will be required in that case.

The schema as it is provides very little opportunity for automated matching between applications and devices. Essentially the only fields with reliable values are interface/protocol and available. This isn't enough to distinguish between cameras, microphones, thermometers, etc. Is automated matching a goal, or will the matching always be manual?

the information about the type of sensors is not a property of the peripheral. Usually this info is gathered from the peripheral description. That's why I was proposing to put it in name. A type field would be useful, but I'm sure the automated matching would need to be done by us on the NuvlaBox, and would be limited

loomis commented 5 years ago

@cjdcordeiro Ok, so we agree that automated matching of peripherals is out of scope and won't be supported?

cjdcordeiro commented 5 years ago

@loomis not for now at least. Can always be added later on.

cjdcordeiro commented 5 years ago

@loomis a few extras for the schema: