Support case-insensitive match for datastore names

[venilnoronha]

Docker, by default, turns volume names to lower-case before providing it to the vDVS plugin on Windows. For example, the volume name in docker volume create --driver=vsphere vol@vsanDatastore is transformed to vol@vsandatastore in Docker API requests, causing a failure. Therefore, we should employ a first-match (or any other) mechanism on the VMDKOps Service and still enable volume creation on vsanDatastore for a better customer experience.

/cc @msterin

[msterin]

To clarify - this issue is to support datastore names like vsanDatastore. if Docker passes us a volume name all lowcase e.g. myvolume@vsandatastore our ESX-side code needs to:

• (low priority) know that this request is coming from Windows VM (we need to add something in the protocol). Generally, we can do the item below for all platforms since 2 datastores different only in letter case would requires customer manually messing it up, and it's super unlikeley
• (top priority) match vsandatastore with vsanDatastore.
• (low priority) we can check there are no case-sensitive names matching the same, and issue a warning if there is (very low priority as it's a real bad practice anyways).

[pshahzeb]

If we plan to go with top priority fix, i.e. match vsandatastore with vsanDatastore:

The fix would be to do a case insensitive match on ESX-side code.

The obvious follow-up question is how do we handle two datastores with same name but different cases mounted on ESX:
eg: vsandatastore and vsanDatastore are two different datastores mounted. This is allowed by vcenter.

we can check there are no case-sensitive names matching the same, and issue a warning if there is (very low priority as it's a real bad practice anyways).

In such a case should we return an error ? We cannot issue just a warning because we need to make a choice out of the available datastores.
What do you guys think?
@msterin @lipingxue @pdhamdhere

[shaominchen]

Here's my suggestion:

1. For GA release, we need a minimal fix that at lease makes sure the default "vsanDatastore" works for Windows. Instead of changing existing case-sensitive logic on ESX side, I'd suggest just do a hard-coded mapping from "vsandatastore" to "vsanDatastore". This quick fix (workaround actually) will be straightforward and most importantly, it's absolutely safe - it won't cause any regression at this point.
2. After GA, we should consider a right fix to take care of all comprehensive scenarios.
3. As for the scenario where two datastores with same name but different cases, as Mark said, this is really bad practice. I think we can just return an error in such case.

Comments?

[shuklanirdesh82]

For GA release, we need a minimal fix that at lease makes sure the default "vsanDatastore" works for Windows. Instead of changing existing case-sensitive logic on ESX side, I'd suggest just do a hard-coded mapping from "vsandatastore" to "vsanDatastore". This quick fix (workaround actually) will be straightforward and most importantly, it's absolutely safe - it won't cause any regression at this point.

It is more harmful than going with no fix + document known issue. how can we just assume it is vsanDatastore ?

[msterin]

Instead of changing existing case-sensitive logic on ESX side, I'd suggest just do a hard-coded mapping from "vsandatastore" to "vsanDatastore".

Unfortunately is won't help for names like Datastore1 or MyDS so the bug will stay.

In such a case should we return an error ? We cannot issue just a warning because we need to make a choice out of the available datastores.

Makes sense. Something like this. right:

> docker create volume -f vsphere myvol
Error:  there are 2 datastores matching the request: dataStore1 and DATASTORE1. 
Case sensitive datastore names are not supported on Windows Vsphere Storage for Docker

[shaominchen]

@shuklanirdesh82 we want to make sure at least the default configuration will work.

@msterin Yes, you are right. It won't help for names like Datastore1 or MyDS. Shahzeb and I had some discussion offline. We will sync up with you.

[shaominchen]

Per offline discussion with @pshahzeb and @msterin, we decided to go with this approach:

1. Do a case insensitive match on ESX side, i.e. match vsandatastore with vsanDatastore
2. Report error if two datastores with same name but different cases are found