Difference between revisions of "Tacker/terminology"
(→Tacker terminology) |
m (Sridhar Ramaswamy moved page ServiceVM/terminology to Tacker/terminology) |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | = | + | = Background = |
So far the terminology are defined by service vm and device manager independently. | So far the terminology are defined by service vm and device manager independently. | ||
Converged terminology is needed. | Converged terminology is needed. | ||
| Line 6: | Line 6: | ||
NOTE: same terminology can be used for different meanings | NOTE: same terminology can be used for different meanings | ||
| − | + | = Tacker terminology = | |
* Device template | * Device template | ||
A template (i.e., a set of defining properties) from which device instances can be created. | A template (i.e., a set of defining properties) from which device instances can be created. | ||
| Line 14: | Line 14: | ||
* Service type | * Service type | ||
* Service instance | * Service instance | ||
| − | A logical resource instance of some Openstack (or Openstack-based) service. [''Should be aligned with at least Neutron's service instance definition''] | + | 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 | * 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. | 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 | * Device driver | ||
* Management 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 address (replace with management URI or similar?) | ||
* Management service driver | * 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 | * Management service address | ||
| − | [''Bob: Do we have any examples where management address of service differs from management address of device? | + | [''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 call | ||
* Management service call | * Management service call | ||
Latest revision as of 17:49, 19 May 2015
Background
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
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
