|
|
@@ -16,5 +16,22 @@ It is intended as a reference.
|
|
|
in the same zone. By requiring the zone across the board, it is less likely to
|
|
|
lead to a miss match. (Related to 63_.)
|
|
|
|
|
|
+- **Name property updates will result in cloud-dependent code.**
|
|
|
+
|
|
|
+ Some providers (e.g., GCE, Azure) do not allow names of resources to be
|
|
|
+ changed after a resource has been created. Similarly, AWS does not allow VM
|
|
|
+ firewall (i.e., security group) names to be changed. Providers seem to be
|
|
|
+ gravitating toward use of tags (or labels) to support arbitrary naming and
|
|
|
+ name changes. Yet, OpenStack for example, does not have a concept of resource
|
|
|
+ tags so CloudBridge cannot rely solely on tags. Further, tags do not need to
|
|
|
+ be unique across multiple resources, while names do (at least for some
|
|
|
+ resources, such as vmfirewalls within a private network). Overall, consistency
|
|
|
+ is challenging to achieve with resource renaming. With that, CloudBridge will
|
|
|
+ support resource renaming to the best extent possible and balance between the
|
|
|
+ use of resource name property and resource tags. However, because of the
|
|
|
+ inconsistency of rename functionality across the providers, using the rename
|
|
|
+ capabilities within CloudBridge will lead to cloud-dependent code. (Related to
|
|
|
+ 131_.)
|
|
|
|
|
|
.. _63: https://github.com/CloudVE/cloudbridge/issues/63
|
|
|
+ .. _131: https://github.com/CloudVE/cloudbridge/issues/131
|