Difference between revisions of "Tacker/terminology"
(created first version) |
(→ServiceVM Terminology) |
||
| Line 9: | Line 9: | ||
TODO | TODO | ||
| − | == | + | == Tacker terminology == |
| − | * device | + | * Device template |
| − | * hosting | + | A template (i.e., a set of defining properties) from which device instances can be created. |
| − | * | + | * Hosting device (or possibly just Device) |
| − | * | + | A device instance capable of hosting service instances. These instances can be virtual (e.g., a VM) or physical(?). |
| − | * service instance | + | * Service |
| − | * device driver | + | * Service type |
| − | * | + | * Service instance |
| − | * management | + | A logical resource instance of some Openstack (or Openstack-based) service. [''Should be aligned with at least Neutron's service instance definition''] |
| − | * | + | * Device management subsystem driver |
| − | * management service address | + | Driver for system or service used by Tacker to manage (e.g., CRUD) a device. Examples of such services are Nova and Heat. |
| − | * | + | * Device driver |
| − | * | + | * Management driver |
| − | * | + | ["Bob: Not sure what this driver should do. Services that use a hosting device for sure needs a driver to instantiate and manage their service instances but I don't think Tacker needs to be aware of those drivers, so what remains?"] |
| + | * Management address (replace with management URI or similar?) | ||
| + | * Management service driver | ||
| + | ["Bob: I'm inclined to say service driver is out of scope for Tacker. We should strive to be service agnostic"] | ||
| + | * Management service address | ||
| + | [''Bob: Do we have any examples where management address of service differs from management address of device?' Unless we do, I suggest we remove this"] | ||
| + | * Management call | ||
| + | * Management service call | ||
| + | * Service device binding | ||
* RPC proxy agent | * RPC proxy agent | ||
| − | * | + | * Proxy management port |
| − | * | + | * Proxy service port |
| − | |||
== common terminology == | == common terminology == | ||
Those terminology are same | Those terminology are same | ||
Revision as of 22:38, 16 July 2014
Contents
ServiceVM/DeviceManager terminology
So far the terminology are defined by service vm and device manager independently. Converged terminology is needed. At first hash out those terminology and find common one.
NOTE: same terminology can be used for different meanings
DeviceManager Terminology
TODO
Tacker terminology
- Device template
A template (i.e., a set of defining properties) from which device instances can be created.
- Hosting device (or possibly just Device)
A device instance capable of hosting service instances. These instances can be virtual (e.g., a VM) or physical(?).
- Service
- Service type
- Service instance
A logical resource instance of some Openstack (or Openstack-based) service. [Should be aligned with at least Neutron's service instance definition]
- Device management subsystem driver
Driver for system or service used by Tacker to manage (e.g., CRUD) a device. Examples of such services are Nova and Heat.
- Device driver
- Management driver
["Bob: Not sure what this driver should do. Services that use a hosting device for sure needs a driver to instantiate and manage their service instances but I don't think Tacker needs to be aware of those drivers, so what remains?"]
- Management address (replace with management URI or similar?)
- Management service driver
["Bob: I'm inclined to say service driver is out of scope for Tacker. We should strive to be service agnostic"]
- Management service address
[Bob: Do we have any examples where management address of service differs from management address of device?' Unless we do, I suggest we remove this"]
- Management call
- Management service call
- Service device binding
- RPC proxy agent
- Proxy management port
- Proxy service port
common terminology
Those terminology are same
