concepts.rst 3.3 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879
  1. Concepts and Organisation
  2. =========================
  3. Object types
  4. ------------
  5. Conceptually, CloudBridge consists of the following types of objects.
  6. 1. Providers - Represents a connection to a cloud provider, and is
  7. the gateway to using its services.
  8. 2. Services - Represents a service provided by a cloud provider,
  9. such as its compute service, storage service, networking service etc.
  10. Services may in turn be divided into smaller services. Smaller services
  11. tend to have uniform methods, such as create, find and list. For example,
  12. InstanceService.list(), InstanceService.find() etc. which can be used
  13. to access cloud resources. Larger services tend to provide organisational
  14. structure only. For example, the storage service provides access to
  15. the VolumeService, SnapshotService and BucketService.
  16. 3. Resources - resources are objects returned by a service,
  17. and represent a remote resource. For example, InstanceService.list()
  18. will return a list of Instance objects, which can be used to manipulate
  19. an instance. Similarly, VolumeService.create() will return a Volume object.
  20. .. image:: images/object_relationships_overview.svg
  21. The actual source code structure of CloudBridge also mirrors this organisation.
  22. Object identification and naming
  23. ---------------------------------
  24. In order to function uniformly across cloud providers, object identity
  25. and naming must be conceptually consistent. In CloudBridge, there are three
  26. main properties for identifying and naming an object.
  27. 1.Id - The `id` corresponds to a unique identifier that can be reliably used to
  28. reference a resource. All CloudBridge resources have an id. Most methods in
  29. CloudBridge services, such as `get`, use the `id` property to identify and
  30. retrieve objects.
  31. 2. Name - The `name` property is a more human-readable identifier for
  32. a particular resource, and is often useful to display to the end user instead
  33. of the `id`. While it is often unique, it is not guaranteed to be so, and
  34. therefore, the `id` property must always be used for uniquely identifying
  35. objects. All CloudBridge resources have a `name` property. The `name` property
  36. is often assigned during resource creation, and is often derived from the
  37. `label` property by appending some unique characters to it. Once assigned
  38. however, it is unchangeable.
  39. 3. Label - Most resources also support a `label` property, which is a user
  40. changeable value that can be used to describe an object. When creating
  41. resources, cloudbridge often accepts a `label` property as a parameter.
  42. The `name` property is derived from the `label`, by appending some unique
  43. characters to it. However, there are some resources which do not support a
  44. `label` property, such as key pairs and buckets. In the latter case, the
  45. `name` can be specified during resource creation, but cannot be changed
  46. thereafter.
  47. Detailed class relationships
  48. ----------------------------
  49. The following diagram shows a typical provider object graph and the relationship
  50. between services.
  51. .. raw:: html
  52. <object data="_images/object_relationships_detailed.svg" type="image/svg+xml"></object>
  53. Some services are nested. For example, to access the instance service, you can
  54. use `provider.compute.instances`. Similarly, to get a list of all instances,
  55. you can use the following code.
  56. .. code-block:: python
  57. instances = provider.compute.instances.list()
  58. print(instances[0].name)