mbraceproject / MBrace.Azure

Microsoft Azure PaaS implementation for MBrace
http://mbrace.io
Apache License 2.0
46 stars 23 forks source link

Provisioning cluster does not install MBrace #133

Open tpetricek opened 8 years ago

tpetricek commented 8 years ago

I tried provisioning a cluster using the tutorial script. However, it never installs anything on the provisioned service. Calling ShowInfo (after about 10 minutes) gives:

 Name           Region        VM size  #Instances  Deployment Status  Storage Accnt   ServiceBus Accnt  Last Modified        Cluster Label 
 ----           ------        -------  ----------  -----------------  -------------   ----------------  -------------        ------------- 
 mbrace-test-1  North Europe  N/A      N/A         None               mbracefbf925e2  mbracea4b750a0    29/12/2015 02:17:02  N/A           

The log printed earlier shows:

INFO : using vm size Small
INFO : using cluster name mbrace-test-1
INFO : reusing inactive service bus account "mbracea4b750a0"
INFO : reusing inactive storage account "mbracefbf925e2"
INFO : creating cloud service "mbrace-test-1"
INFO : starting deployment "mbrace-test-1" using slot "Production" with package "https://mbracefbf925e2.blob.core.windows.net/deployments/MBrace.Azure.CloudService-Small.cspkg-a5f3tyaaukqauafcs6l4hk9jas-782856"

val deployment : Deployment

I noticed that the URL (https://mbracefbf925e2.blob.core.windows.net/deployments/MBrace.Azure.CloudService-Small.cspkg-a5f3tyaaukqauafcs6l4hk9jas-782856) leads to a page that gives HTTP 404. Is this an bug?

tpetricek commented 8 years ago

Hmm, choosing another service (medium rather than small) and another region seems to be solving the problem. I guess something failed earlier and got cached somewhere...

eiriktsarpalis commented 8 years ago

Hi Tomas! The reason you are seeing this issue is because Small and ExtraSmall instances are silently rejected by the Azure management library. We should probably ensure that an error is thrown, or remove those sizes altogether.

dsyme commented 8 years ago

Let's remove those sizes then

tpetricek commented 8 years ago

Aaah, good to know :) Feel free to close this issue then. Thanks!

isaacabraham commented 8 years ago

Now that I've finally gotten around to surfacing the errors that Azure reports (contrary to the above, the Azure management library does surface these errors - they were just not being trapped by the MBrace management library), this is what you get with ExtraSmall / Small VMs: -

Validation Errors: Total requested resources are too large for the specified VM size

In other words, we've probably set the required disk space and / or memory levels in the cloud service too high. Theoretically we might be able to work around this to re-enable these sizes, but at the same time I'm not sure if it's recommended to use these VMs anyway as they are so small - single core and 0.75GB / 1.75GB ram respectively.

isaacabraham commented 8 years ago

I did a bit more digging about. Currently the Cloud Service has two local resources: -

  1. DiagnosticStore (20GB)
  2. LocalMBraceCache (400GB)

It's the second one that's popping the local resource limits for both Extra Small (16GB) and Small (200GB).

Any objection to me lowering the Local MBrace Cache size to, say, 150GB? It appears that this is used as TMP, TEMP and the working directory of MBrace Azure.

The alternative is that we do a modified build for Small VMs that have the 150GB restriction but leave the rest as 400GB.

I'm going to remove Extra Small from the permitted set of VM sizes, it's too small to be useful.

cc: @eiriktsarpalis @dsyme

cgravill commented 8 years ago

Reducing the minimum size requirement on LocalMBraceCache would be really useful for supporting the D-series virtual machines. They have better compute than corresponding As but fairly low storage e.g. I tried to start with a D3_v2 with 4 cores, which failed with "Total requested resources are too large for the specified VM size."

I've previously dealt with this by reducing LocalMBraceCache locally myself but the new provisioning system looks really convenient. Is it even possible for e.g. MBrace.Azure.CloudService-Standard_D3_v2.cspkg to work as created?