This guide describes common problems encountered when deploying applications.
The error Invalid YAML: Plan not in acceptable format: Cannot convert ...
means that the text is not valid YAML. Common reasons include that the indentation is incorrect, or that there are non-matching brackets.
The error Unrecognized application blueprint format: no services defined
means that the services:
section is missing.
An error like Deployment plan item io.brooklyn.camp.spi.pdp.Service@23c159e2[name=<null>,description=<null>,serviceType=com.acme.Foo,characteristics=[],customAttributes={}] cannot be matched
means that the given entity type (in this case com.acme.Foo) is not in the catalog or on the classpath.
An error like Illegal parameter for 'location' (aws-ec3); not resolvable: java.util.NoSuchElementException: Unknown location 'aws-ec3': either this location is not recognised or there is a problem with location resolver configuration
means that the given location (in this case aws-ec3) was unknown. This means it does not match any of the named locations in brooklyn.properties, nor any of the clouds enabled in the jclouds support, nor any of the locations added dynamically through the catalog API.
There are many stages at which VM provisioning can fail! An error Failure running task provisioning
means there was some problem obtaining or connecting to the machine.
An error like ... Not authorized to access cloud ...
usually means the wrong identity/credential was used.
An error like Unable to match required VM template constraints
means that a matching image (e.g. AMI in AWS terminology) could not be found. This could be because an incorrect explicit image id was supplied, or because the match-criteria could not be satisfied using the given images available in the given cloud. The first time this error is encountered, a listing of all images in that cloud/region will be written to the debug log.
Failure to form an ssh connection to the newly provisioned VM can be reported in several different ways, depending on the nature of the error. This breaks down into failures at different points:
... could not connect to any ip address port 22 on node ...
).... Exhausted available authentication methods ...
).There are many possible reasons for this ssh failure, which include:
machineCreateAttempts
configuration option, to automatically retry with a new VM.loginUser
configuration option. An example of this is with some Ubuntu VMs, where the “ubuntu” user should be used. However, on some clouds it defaults to trying to ssh as “root”.A very useful debug configuration is to set destroyOnFailure
to false. This will allow ssh failures to be more easily investigated.
A common generic error message is that there was a timeout waiting for service-up.
This just means that the entity did not get to service-up in the pre-defined time period (the default is two minutes, and can be configured using the start.timeout
config key; the timer begins after the start tasks are completed).
See the guide on runtime errors for where to find additional information, especially the section on “Entity's Error Status”.