Name simplification of ibmcloud provider and resources

[renier]

The name "ibmcloud" is redundant. You don't see other providers here suffixing with "cloud". For example, the Google Cloud provider is just called "google". Amazon is just "aws" and so forth. Given we will have lots of resources and names can get long, it would be good to reduce the provider name now to just "ibm". The name in the documentation can still say "IBM Cloud" as Google Cloud has it, but the provider name should be as short as possible: "ibm".

As for other the other pieces of the naming. It seems "cf" is reserved for resources related to cloud foundry; "cs" for resources related to clusters?

I believe "infra" should just say "sl" (for SoftLayer). It is simply the current underlying platform for infrastructure resources, the same as Cloud Foundry ("cf") is the current underlying platform for PaaS resources. "sl" is also a shorter abbreviation than "infra" and matches the character length for the other category abbreviations.

Ideally we would not need such secondary naming fragments. Is it possible to do away with those? Doing away with "cs", "cf", and "infra", you would have "ibm_virtual_guest" and "ibm_cluster" resources. Simpler. Otherwise, shorten ibm_infra to ibm_sl.

This should not be discounted. Developer Experience with regards to cloud services and their use is paramount. A simple and clean naming scheme helps the community understand, remember and assimilate the kinds of cloud resources that a particular platform has to offer.

[ckelner]

@davetropeano thoughts?

[ckelner]

@renier I agree, and if we're ever to do it, now would be the time. However I think this is Dave's call.

[albee-jhoney]

I have the following opinion - with the observations made by @renier

• "The name "ibmcloud" is redundant"
  • between "ibm" & "ibmcloud" -- I prefer "ibmcloud"
• "infra" should just say "sl" (for SoftLayer).
  • I prefer to use a generic name "infra", rather than a brand name "softlayer", etc..
  • for the same reason, we did not use "bluemix"
• "not need such secondary naming fragments."
  • we have noticed conflicts in the names of softlayer & bluemix resources - hence grouping them make it easy for readability & maintainability.
• "Developer Experience with regards to cloud services and their use is paramount."
  • agreed, so is readability, maintainability of the hcl/tf file..
  • with the code gen tools & graphical visualisation - I believe, this will not be a significant deterrent.

@vkalangu @ashishth09 - your comments..

[ashishth09]

First thing, all are subjective points and we are trying hard to come up with the best. I agree with @albee-jhoney on most points.

I was looking into the current implementations and few things that stand out are -

• Alicloud - They don't call it Alibabacloud or Alibaba, just alicloud

My only concern thus far is for infra ones. How are we going to name new resources when they are available and might do the same thing

[renier]

@albee-jhoney @ashishth09

between "ibm" & "ibmcloud" -- I prefer "ibmcloud"

Can you elaborate why? Why is specifying "cloud" necessary? Other popular providers are not doing this and benefit from the brevity in the resource names.

I prefer to use a generic name "infra", rather than a brand name "softlayer", etc..
for the same reason, we did not use "bluemix"

Note that this is not about branding, but about underlying platform. You are already using cf and cs for other resources. Two-letter acronyms to identify the platform or subsystem. infra is even more generic and different in length from the other two. It does not match the taxonomy already established.

we have noticed conflicts in the names of softlayer & bluemix resources - hence grouping them make it easy for readability & maintainability.

I wonder why would we have duplicate resources across the two. Can you provide an example of this?

with the code gen tools & graphical visualisation - I believe, this will not be a significant deterrent.

Keep in mind that your users will not just be users of the code gen and UIs you create. Users will also simply use Terraform on their own with their own API keys. You don't want to dissuade that type of usage.

[ashishth09]

@renier ,

I wonder why would we have duplicate resources across the two. Can you provide an example of this?

Ex - softlayer_user , assuming it were just ibm_user to mean softlayer_user then we can't introduce bluemix user without inventing other name for the user resource.

Having said that now the discussion is more on settling for the right secondary fragments ex- ibmcloud_infra/sl.

Can you elaborate why? Why is specifying "cloud" necessary? Other popular providers are not doing this and benefit from the brevity in the resource names.

The name aws itself stands for the Amazon cloud, it is the name of their cloud. For them adding cloud is redundant. So is azure, if they didn't had , may be they would call themselves Microsoft and not even add cloud as that would certainly be verbose. Same with digital ocean and so on. Their product stands for the cloud itself with the given name.

We don't have a name for our cloud yet and hence the suffix cloud.

[renier]

@ashishth09

softlayer_user , assuming it were just ibm_user to mean softlayer_user then we can't introduce bluemix user without inventing other name for the user resource.

Can you create a bluemix user solely through its API? Doesn't that use the separate IAM system (which SoftLayer uses as well, btw), which requires an email confirmation from the user? I was hoping for a better example where two or more of the underlying subsystems (cf, cs, infra) could provide the same type of resource. Users are already created through a shared system, IAM, which softlayer_user supports.

The name aws itself stands for the Amazon cloud, it is the name of their cloud. For them adding cloud is redundant. So is azure, if they didn't had , may be they would call themselves Microsoft and not even add cloud as that would certainly be verbose. Same with digital ocean and so on. Their product stands for the cloud itself with the given name.
We don't have a name for our cloud yet and hence the suffix cloud.

What about Google? Their resource names are, e.g., google_storage_container or google_project. The title for the provider is Google Cloud, but they didn't add cloud to the provider name. It is just google.

Having them done that, do we think that confuses their users about whether those resources are for their cloud? Absolutely not, because all providers in Terraform (with few exceptions) are for the Cloud platform or for Cloud-based services.

[ashishth09]

@renier,

Can you create a bluemix user solely through its API? Doesn't that use the separate IAM system (which SoftLayer uses as well, btw), which requires an email confirmation from the user?

bluemix_user -> cf_user (though unimplemented or probably never) but the point I am trying to make is, can there be another user resource in the whole IBM Cloud or not? There will be some resources like users, account etc which are not real-world infrastructure but whose life-cycle we would be interested to manage. More importantly these resources might fall in different back-end platforms due to the heterogeneous nature of our cloud at this point. Things will merge sooner or later for the unification but until then I guess we can't simply put ibm_user without the back-end specified. This states the necessity to have the secondary fragments.

On that note I am OK with putting ibmcloud_sl. But then my previous concern, what if x provides virtual guest as well. Do we roll out ibm_x_virtual_guest? I have no clue about this one at this point.
That would be a separate discussion I guess.

I spent some more time looking at other providers. Surprised to see Oracle call itself just opc, (Oracle Public Cloud). So probably they are focusing on brevity as well. I see following trends then
either your name represents

• your cloud division brand - aws, alicloud (chinese aliyun 😃 )
• just your name - google,
• acronym - opc, vcd etc

I guess with that trend we can go with just our name. Probably the trend should convince others as well 😃

[renier]

@ashishth09 Ok, ideally we would not need suffixes, but admittedly it's complicated to do right now while the platform merges into one cohesive set of APIs over time.

About the provider name, yes, I think we are agreeing on going with ibm for the provider name, while the documentation can continue to say IBM Cloud.

About the _infra_ suffix, I think we are agreeing on going with _sl_, then.

[albee-jhoney]

I am also ok with ibm instead of ibmcloud.

re: _sl_ instead of _infra_, I suggest that we use _is_ (as an acronym for "infrastructure service", like _cs_ for "container service", and so on.)

[renier]

re: _sl_ instead of _infra_, I suggest that we use _is_ (as an acronym for "infrastructure service", like _cs_ for "container service", and so on.)

@albee-jhoney I can agree with that.

[rbmateescu]

While I think the proposed changes make sense in general, I'd like to point out that they will have some impact on products using the driver already, especially around data migration (customers having running instances will need to be migrated to the new provider) which may slow down the adoption of the newer versions of the driver.

[albee-jhoney]

Refer to #145 for the new names, and its mapping to the older resource names.