> I don't think any of the other providers require the region to be included in > the hardwareId, so ideally we shouldn't require it for GCE. (Is that statement true? Do any other providers include the region/zone in the hardwareId?)
I think this statement is tricky, because it assumes we (and users) know in advance how hardware IDs are encoded internally in the provider. But we should assume we don't even know they are URIs! jclouds interfaces are prepared to work fine with hardware IDs whatever format they have, even if they are URIs, strings that encode additional information, etc. We don't care. Whatever the provider API says "this is how you should uniquely identify this hardware profile", we use that. As soon as we start making our own assumptions and parsing, we are opening the door to future issues when things change in the provider (hopefully never). My concerns are that the current code and behavior is consistent, does not make any assumption on how the cloud provider works, and meets the contract of the jclouds interfaces, but changing this to shorten the hardware profile id, compromises the above, just to provide a sugar when specifying the hardware profile id. I understand that having URIs with the location encoded in them can look ugly, or not convenient for some use cases (and it is not jclouds the one who made the choice of how hardware profile ids are identified in GCE), but IMO that logic could be better/easily implemented in the applications that use jclouds? I'm just putting in a balance the trade-offs and the gains of the patch. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/951#issuecomment-217159705
