design-decisions.rst 2.0 KB

12345678910111213141516171819202122232425262728293031323334353637
  1. Design decisions
  2. ~~~~~~~~~~~~~~~~
  3. This document captures outcomes and, in some cases, the through process behind
  4. some of the design decisions that took place while architecting CloudBridge.
  5. It is intended as a reference.
  6. - **Require zone parameter when creating a default subnet.**
  7. Placement zone is required because it is an explicit application decision,
  8. even though ideally *default* would not require input. Before requiring it,
  9. the implementations would create a subnet in each availability zone and return
  10. the first one in the list. This could potentially return different values over
  11. time. Another factor influencing the decision was the example of creating a
  12. volume followed by creating an instance with presumably the two needing to be
  13. in the same zone. By requiring the zone across the board, it is less likely to
  14. lead to a miss match. (Related to 63_.)
  15. - **Name property updates will result in cloud-dependent code.**
  16. Some providers (e.g., GCE, Azure) do not allow names of resources to be
  17. changed after a resource has been created. Similarly, AWS does not allow VM
  18. firewall (i.e., security group) names to be changed. Providers seem to be
  19. gravitating toward use of tags (or labels) to support arbitrary naming and
  20. name changes. Yet, OpenStack for example, does not have a concept of resource
  21. tags so CloudBridge cannot rely solely on tags. Further, tags do not need to
  22. be unique across multiple resources, while names do (at least for some
  23. resources, such as vmfirewalls within a private network). Overall, consistency
  24. is challenging to achieve with resource renaming. With that, CloudBridge will
  25. support resource renaming to the best extent possible and balance between the
  26. use of resource name property and resource tags. However, because of the
  27. inconsistency of rename functionality across the providers, using the rename
  28. capabilities within CloudBridge will lead to cloud-dependent code. (Related to
  29. 131_.)
  30. .. _63: https://github.com/CloudVE/cloudbridge/issues/63
  31. .. _131: https://github.com/CloudVE/cloudbridge/issues/131