none
hpcsync fails due to long path

    Question

  • Hi,

    I am trying to deploy a service to azure nodes using a default azure node template, I use the following command, (After creating the package using "hpcpack create ..." and uploading it using "hpcpack upload ...")

    clusrun /nodegroup:AzureNodes hpcsync

    it fails due to long path, given the 256 chars limitation that exist.

    Is there any workaround?

    Thanks!

    Thursday, March 2, 2017 9:56 AM

All replies

  • Hi,

    I have now used 

    clusrun /nodegroup:AzureNodes hpcsync c:\MyPath

    in order to upload the service to c:\MyPath directory instead of the default %CCP_PACKAGE_ROOT% but the troble is now when I want to do load test (and presumably when I run my app) my service configuration file cannot be found.

    What do you suggest please?

    Thursday, March 2, 2017 1:29 PM
  • Hi Again,

    I have found the command 'cluscfg' which I can run like this:

    cluscfg setenvs "CCP_PACKAGE_ROOT=c:\MyPath"

    This however doesn't seem to have any effect on the Azure nodes. They are up and running and taking them down and bringing them on again after running above command does not make any difference either. I even tried to stop them and start them again, which goes through the provisioning them again, but it does not make a difference.

    Can someone please help with some suggestion how can I make this change so that %CCP_PACKAGE_ROOT% point to c:\MyPath on the Azure nodes!

    Thanks!

    Thursday, March 2, 2017 2:41 PM
  • Hi, Could you tell me why it exceeds 256 chars? Is it because your file name is very long or you have lots of sub-folders in the uploaded package?

    In whatever situation you could try below approach:

    1. Split the service registration file and your service file into two packages

    2. UPload the service package to C:\MyPath as you've already done

    3. Modify the Service registration file, give the absolute path to your service assembly, for example, in your case "c:\MyPath\...\MyAssembly.dll"

    4. Give a short name for the Service registration file, and just upload and sync to the CCP_PACKAGE_ROOT so that it will be find by our service; and our service will try get the service registration file path through the value you gave, if it can't find in the give path, it will try to find it under CCP_PACKAGE_ROOT

    Hope this works for you.


    Qiufang Shi

    Friday, March 3, 2017 8:41 AM
  • Hi,

    Ok, the reason for long path is not long file names, but the directory structure.

    I have tried your suggestion and I got this when in configure Tab, I try testing SOA service load test:

    [Main]: Cannot find the assembly file: C:\Resources\directory\0af7d69ec5414be59349108c82609d8e.HpcWorkerRole1.Microsoft.Hpc.Azure.LocalStorage.Application\MyService\2017-03-08T145528.0000000Z\Service.dll. Redeploy service. 

    Then I added MyService.dll and these Microsoft HPC dlls to the package:

    Microsoft.Hpc.Azure.DataMovement.dll
    Microsoft.Hpc.Scheduler.dll
    Microsoft.Hpc.Scheduler.Properties.dll
    Microsoft.Hpc.Scheduler.Session.dll

    (There was some hint in the error that I was getting about not being able to find HPC.Session dll which is why I copied these into the package)

    After doing that when I try  Configuration >> Services >> MyService >>Run SOA Service Loading Diagnostics Test

    It reports Success.

    But

    When I run my application (Which runs fine on the on-premise grid by the way), it comes back asking for dependent dlls, and if I add the first one to the package it asks for the next one and the next, etc. etc. As if it ignores the assembly location in my service registration config file and expect to see everything in default location. 

    I do appreciate you help!

    Wednesday, March 8, 2017 4:16 PM
  • I must say that I could not get round this problem, But, I found out the minimum required set of dependencies and just having those did not violate the max path length limitation and so I am sorted.

    Thanks

    Thursday, March 9, 2017 9:24 AM