why do you want to use remote desktop?
I often just use mbrace to perform adminstrative stuff on my nodes
processes run with admin rights so you can do whatever you want with the nodes' state
I need each node of the cluster to have one tcp port open to outside the cluster/cloud service, ideally only accepting connections from a given host, but for now I'd like to have it work without restrictions, I've added a InputEndPoint
<InputEndpoint name="MyEndPoint" protocol="tcp" port="22222" />
is there a plan to move mbrace.azure to most recent azure APIs (https://github.com/Azure/azure-sdk-for-net), I intend to use those bits in my .net codebase and it is confusing to have all those Microsoft.WindowsAzure.* + Microsoft.Azure dependencies
I'm slowly figuring things out on all the bits I need to use and the azure development story is a bumpy ride (took me very long to find what is most recent SDK bits, but almost no documentation for it), departing from "complete azure newbie" involves lots of tedious searches in a jungle of APIs, outdated blog posts, msdn doc lagging a lot in showing the current SDK, and frustrating trial/errors to setup authorizations (need to setup classic AD for using most of that azure-sdk-for-net stuff)
and they will be seeing eachother
Hi @eiriktsarpalis regarding Azure SDK versions, I believe all "WindowsAzure" dependencies are going to be deprecated by new bits (https://github.com/Azure/azure-sdk-for-net), I believe for all the aspects which are exposed under new assemblies (probably storage / Service bus as you mention, but maybe other as well) we should try to favor those.
thanks for explaination about connection strings / making heterogenous cluster, it makes sense, I'm not yet acquainted with the underlying machinery MBrace uses to "make it happen" :)
I'm currently working with pre-release packages because stuff is being added actively just to make sure I don't go and implement my own rest client if something is being handled in their new SDK
if MBrace can migrate away from azure "classic" services wherever it is possible, I think it will now be possible to leverage their better SDK
nevermind, service bus is there: https://github.com/Azure/azure-sdk-for-net/tree/master/src/ServiceManagement/ServiceBus/ServiceBusManagement still under WindowsAzure namespace
which is separate to the function of WindowsAzure.* libraries
MBrace.Azure uses WindowsAzure.* libraries
MBrace.Azure.Management uses the latter
I'm still trying to make the virtualnetwork configuration work from my custom .cspkg, I noticed that when I create a cloud service from classic azure portal, it would ask for both .cspkg and .cscfg files, so I suspect that somehow mbrace should accept both those files instead of just .cspkg
https://github.com/mbraceproject/MBrace.Azure/blob/master/src/MBrace.Azure.Management/Compute.fs#L202 This is called even when I give a cspkg, and it would conflict with the custom configuration I intend to pass (which has a NetworkConfiguration section)
the service definition is honored (since it ends in the .cspkg) but my custom configuration can't be passed
I still get an exception. Shall I post it at the github issue or here?
in my case it contains
#I __SOURCE_DIRECTORY__
#r "tools/Newtonsoft.Json.dll"
#r "tools/FsPickler.Json.dll"
#r "tools/FsPickler.dll"
#r "tools/System.Spatial.dll"
#r "tools/Mono.Cecil.dll"
#r "tools/Vagabond.AssemblyParser.dll"
#r "tools/Vagabond.dll"
#r "tools/Argu.dll"
#r "tools/Microsoft.Data.Edm.dll"
#r "tools/Microsoft.Data.OData.dll"
#r "tools/Microsoft.Data.Services.Client.dll"
#r "tools/Microsoft.ServiceBus.dll"
#r "tools/Microsoft.WindowsAzure.Configuration.dll"
#r "tools/Microsoft.WindowsAzure.Storage.dll"
#r "tools/MBrace.Core.dll"
#r "tools/MBrace.Runtime.dll"
#r "tools/MBrace.Azure.dll"
open System.IO
open MBrace.Azure
AzureWorker.LocalExecutable <- Path.Combine(__SOURCE_DIRECTORY__, "tools/mbrace.azureworker.exe")
I also do see the assemblies under tools folder, are you running on windows?
Red lines: