Trying to deploy using CloudML facade returns a missing credentials error

[rickdesantis]

As in the title, if I try to deploy the model of my infrastructure using the org.cloudml.facade.CloudML class, even though I specify the full path of the credentials file it still laments a "Missing credentials" error (as produced by this line).

This is the beginning part of my model:

{
    "eClass": "net.cloudml.core:CloudMLModel",
    "name": "MiC2AWS",
    "providers": [
        {
            "credentials": "/tmp/scalingrulestests/2406151219/credentialsAmazon.properties",
            "eClass": "net.cloudml.core:Provider",
            "name": "aws-ec2"
        }
    ],
...

I've tried putting the file in the folder in which there's the executable starting the CloudML daemon, but still nothing changed.

This problem doesn't happen when using the web socket client directly with the same model.

As an alternative and good-enough solution for testing purposes, could it be possible to just put the login and password in the model? And if yes, what's the syntax for that?

[rickdesantis]

OK so I've just discovered that this is what the daemon is writing me:

/131.175.135.109:64038 said: !extended { name : LoadDeployment }
/131.175.135.109:64038 said: !additional json-string:{ "eClass":"net.cloudml.core:CloudMLModel" ,
 "name":"MiC2AWS ",
"providers": [
{ "eClass":"net.cloudml.core:Provider" ,
 "name":"aws-ec2"}
]
...

so it is stripping that information somehow? I'm pretty sure that the model I'm sending HAS that information.

[nicolasferry]

Hi Riccardo,

Thanks for the feedback. To help me finding the issue, can you provide me with the following information: How do you create your instance of CloudML? are the CloudML daemon and your tool using the facade located on the same machine?

[rickdesantis]

Thanks for your quick response. The cloudml daemon is running on a vm (on Amazon) while the client runs on my machine. The full path there refers to the file on the machine where the daemon is running.

[nicolasferry]

Ok, so I think this is the issue. The "remote facade" (the one that uses the websocket interface) has been created for integration purpose between Modelio and CloudML. A request from Modelio was that the credentials and SSH keys has to stay on the local machine (the one running modelio and thus the facade) and not on the machine running the daemon. So the remote facade tries to access these files on the machine running the facade.

If this is an issue for you I can create another "mode" where the credentials etc. are assumed to be together with the daemon?

[rickdesantis]

Oh, didn't think about that. Ok then, it's actually better this way. Thanks for your time, hopefully everything will work as expected now.

Closing this issue report.

[rickdesantis]

Gotta reopen this. It indeed works as expected with that facade, but now I'm trying using directly the web socket client and something similar is happening there too, so I'm just reusing this issue.

I give it the remote paths (the paths on the machine where the daemon is running) because local paths returns the "Missing credentials" error above. The deploy works, but when it is finished I read these messages on the log of the daemon:

...
Jun 24, 2015 4:43:05 PM org.cloudml.mrt.Coordinator updateStatusInternalComponent
INFO: >> Updating the model..
Jun 24, 2015 4:43:05 PM org.cloudml.mrt.Coordinator updateStatusInternalComponent
INFO: >> Status of: appInstance changed in: RUNNING
Jun 24, 2015 4:43:05 PM org.cloudml.connectors.JCloudsConnector closeConnection
INFO: >> Closing connection ...
Jun 24, 2015 4:43:05 PM org.cloudml.core.credentials.FileCredentials initializeCredentials
SEVERE: Missing credentials
Jun 24, 2015 4:43:05 PM org.cloudml.core.credentials.FileCredentials initializeCredentials
SEVERE: Missing credentials

and it fails to give me the acknowledge of finished deployment (which my code is waiting for for unblocking itself, as I'm simulating a blocking execution also for the deploy). I was testing the CloudML facade to check if the deploy was blocking there, but it isn't, even if I use the fireAndWait method.

Having the daemon and the client on the same machine won't show this bug.

Any idea? Fixing the deploy to be "blocking" won't help me, as I'd prefer to use directly the web socket for slimming the dependencies of my project.

[nicolasferry]

Hello, I tried to replay a deployment in a context similar to yours and it worked properly so I believe there are still some slight in differences in our configurations. I see from your log that the message "Missing credentials" appears several times, did you declare several cloud providers in your model? in such case did you uploaded all the credential files on the daemon side?

[rickdesantis]

I'm using only one provider. That message is shown twice because one is for the getLogin() and one is for the getPassword() :) This is the log that was shown when it did happen with the CloudML facade:

12:08:32.605 [Thread-1] DEBUG org.cloudml.facade.CloudML - 
12:08:32.707 [pool-1-thread-1] ERROR org.cloudml.core.Provider - Missing credentials
Caller+0     at org.cloudml.core.credentials.FileCredentials.initializeCredentials(FileCredentials.java:98)
Caller+1     at org.cloudml.core.credentials.FileCredentials.initializeIfNeeded(FileCredentials.java:113)
Caller+2     at org.cloudml.core.credentials.FileCredentials.getLogin(FileCredentials.java:63)
Caller+3     at org.cloudml.facade.RemoteFacade.handle(RemoteFacade.java:105)
Caller+4     at org.cloudml.facade.commands.LoadDeployment.execute(LoadDeployment.java:43)
12:08:32.709 [pool-1-thread-1] ERROR org.cloudml.core.Provider - Missing credentials
Caller+0     at org.cloudml.core.credentials.FileCredentials.initializeCredentials(FileCredentials.java:98)
Caller+1     at org.cloudml.core.credentials.FileCredentials.initializeIfNeeded(FileCredentials.java:113)
Caller+2     at org.cloudml.core.credentials.FileCredentials.getPassword(FileCredentials.java:69)
Caller+3     at org.cloudml.facade.RemoteFacade.handle(RemoteFacade.java:107)
Caller+4     at org.cloudml.facade.commands.LoadDeployment.execute(LoadDeployment.java:43)

I'm pretty confident that it's showing two messages for this reason. I'm sure that the files were on the daemon machine, also because the deploy and the startCommand at the end of it were executed correctly...

Here is my deployment model. Tell me if you see any problem, because I don't :\

{
    "eClass": "net.cloudml.core:CloudMLModel",
    "name": "MiC2AWS",
    "providers": [
        {
            "credentials": "/tmp/scalingrulestests/2406151837/credentialsAmazon.properties",
            "eClass": "net.cloudml.core:Provider",
            "name": "aws-ec2"
        }
    ],
    "internalComponents": [
        {
            "eClass": "net.cloudml.core:InternalComponent",
            "name": "app",
            "resources": [{
                "eClass": "net.cloudml.core:Resource", 
                "name": "startApp", 
                "startCommand": "bash /home/ubuntu/updateEverything  ;  sudo bash /home/ubuntu/snapshotMICStarter 127.0.0.1 54.77.91.67  ;  source /home/ubuntu/.bashrc  ;  bash /home/ubuntu/startImperialDC ; export AWS_ACCESS_KEY_ID=[censored-lol]  ;  export AWS_SECRET_ACCESS_KEY=[censored-lol]  ;  export AWS_DEFAULT_REGION=eu-west-1  ;  bash /home/ubuntu/add_to_loadBalancer ScalingRules545",
                "stopCommand": "export AWS_ACCESS_KEY_ID=[censored-lol]  ;  export AWS_SECRET_ACCESS_KEY=[censored-lol]  ;  export AWS_DEFAULT_REGION=eu-west-1  ;  bash /home/ubuntu/deregister_from_lb ScalingRules545"
                }
            ],
            "requiredExecutionPlatform" : {
                "eClass" : "net.cloudml.core:RequiredExecutionPlatform",
                "name" : "appRequired",
                "owner" : "internalComponents[app]"
            }
        }
    ],
    "internalComponentInstances": [
        {
            "eClass": "net.cloudml.core:InternalComponentInstance",
            "name": "appInstance",
            "type": "internalComponents[app]",
            "requiredExecutionPlatformInstance" : {
                "eClass" : "net.cloudml.core:RequiredExecutionPlatformInstance",
                "name" : "appRequiredInstance",
                "owner" : "internalComponentInstances[appInstance]",
                "type" : "internalComponents[app]/requiredExecutionPlatform[appRequired]"
            }
        }
    ],
    "vms": [
        {
            "eClass": "net.cloudml.core:VM",
            "imageId": "eu-west-1/ami-ab3f43dc",
            "is64os": true,
            "location": "eu-west-1",
            "providerSpecificTypeName": "m3.large",
            "maxStorage": "8",
            "minStorage": "8",
            "name": "MIC",
            "os": "ubuntu",
            "privateKey": "/tmp/scalingrulestests/2406151837/desantis-ireland.pem",
            "providedExecutionPlatforms": [
                {
                    "eClass": "net.cloudml.core:ProvidedExecutionPlatform",
                    "name": "MICTIER",
                    "offers": [
                        {
                            "eClass": "net.cloudml.core:Property",
                            "name": "OS",
                            "value": "Ubuntu"
                        }
                    ],
                    "owner": "vms[MIC]"
                }
            ],
            "provider": "providers[aws-ec2]",
            "securityGroup": "default",
            "sshKey": "desantis-ireland"
        }
    ],
    "vmInstances": [
        {
            "eClass": "net.cloudml.core:NodeInstance",
            "name": "micInstance264",
            "type": "vms[MIC]",
            "providedExecutionPlatformInstances": [
                {
                    "eClass": "net.cloudml.core:ProvidedExecutionPlatformInstance",
                    "name": "mictier",
                    "owner": "vmInstances[micInstance264]",
                    "type": "vms[MIC]/providedExecutionPlatforms[MICTIER]"
                }
            ]
        }
    ],
    "executesInstances": [
        {
            "eClass": "net.cloudml.core:ExecuteInstance",
            "name": "runApp",
            "providedExecutionPlatformInstance": "vmInstances[micInstance264]/providedExecutionPlatformInstances[mictier]",
            "requiredExecutionPlatformInstance": "internalComponentInstances[appInstance]/requiredExecutionPlatformInstance[appRequiredInstance]"
        }
    ]
}

[nicolasferry]

can you send me also the CloudML log file? I just did a test with your deployment model, CloudML on a remote VM, and the webeditor (so not using the facade) and it worked properly with the ack once completed. The only thing I have change in your model are: the SSHKey, security group, and provider credentials.

[rickdesantis]

I'll be damned, I tried it again and it did work. So maybe it's a random thing for some reason? Sadly I don't have the log for those runs when it didn't work, because it was running on a VM that I did kill.

Maybe it is linked to the statuses == null problem, that is also apparently random? I'll do some other run and I'll send you a log if I met the problem again.

Keeping this report open for now.

[nicolasferry]

Ok many thanks, hopefully the logs will give me some hints on why it did not worked

[rickdesantis]

Closing as I can't reproduce it again.