When i deploy with REST API i receive the following error.
'Failed to set extent: could not find extended service in paths'.
I have resolve with Tomcat (replace extend "../../../services/tomcat" with extend "tomcat") but i have problem with MySql.
This probably occurs because mysql doesn't come with the Cloudify 2.7* distribution zip file.
You need to download (e.g. : git clone https://github.com/CloudifySource/cloudify-recipes.git) and then place the mysql service and specify its relative path in the command.
HTH,
Tamir,
Related
I need to remotly manage the bundles that run on my karaf instances, ideally via HTTP calls or python scripts.
I set up my karaf instance and can access to it at http://mykarafserver:8040/jolokia.
I found just one example of usage in the jolokia website :
{
"type":"read",
"mbean":"java.lang:type=Memory",
"attribute":"HeapMemoryUsage",
"path":"used"
}
and I get a result, but I can't find the urls of Json syntax to start, stop, restart and get status of my bundles. I believe this is possible as some tools like Hawtio can manage Camel and Karaf stuf.
Is it possible to specify linked template deployment file somehow in New-AzureRMResourceGroupDeployment cmdlet without specifying external URL, just like you can do with -TemplateFile parameter locally
No, this is not possible, because Azure has to be able to download it. No real workarounds. Upload and deploy with script
I know using command line it can be get by running feature:list -i but is there any API/JSON available to fetch this?
You can use jolokia and hawtio to retrieve that information. Quite easily. I believe you can easily add the hawtio repo from the native karaf repos in features (repo-add hawtio). Then you need to install jolokio, hawtio, and the karaf web console. From the karaf webconsole alone you can see a full list of features, but I find the hawtio interface to be a god send.
A REST API can be installed without the need for Hawtio, which uses jolokia for accessing the bundle list under the hood.
The jolokia project provides web applications called agents serving a REST API. For quick experiments you can deploy the war jolokia-war-unsecured into the hot deploy folder of a running karaf instance. This installs a A REST web service at e.g. http://localhost/jolokia-war-unsecured/ which does not require any authentications.
I want to publish a maven project to CloudControl by REST API, not by command line tool, is it possible? That means, create a app by REST API, deploy source or binary code by REST API. Just like Heroku, I can build a url directly into app using REST API https://api.heroku.com/apps/myapp/builds. Thanks very much!
We currently don't provide a way to upload images directly. You'd first have to push to the Git remote which will build the image. All other steps like creating an app/deployment, deploying or adding add-ons are available via the REST-API. You can see examples of the API usage in the python library the command line client uses.
I am trying to publish to local file system, however publishing is not happening properly and its failed to deploy in my 2011 GA VM environment.
I am getting "Polling for notification for destination: YTnMgU6u5Vh09cOGUG7ouA== has exceeded polling attempts for transaction: tcm:0-121257-66560" error in "Preparing Deployment" stage.
I have used the “Local File System” protocol in my publication target and I have provided path like d:\tridion\publish.
And I have provided the same path in cd_storage_conf.xml under the <storage type=”filesystem”>. All other storage types are commented.
And in cd_deployer_conf.xml , quee location path is c:\tridion\incoming.
When I publish any page into my publication target, the zipped package is placed in the d:\tridion\publish and it’s not deployed.
Do I need to do any other thing to deploy the zipped package?
The path provided in the cd_deployer_conf.xml (the one you specify in Queue/Location!!!) needs to be the same one you provide in your publication target (in your case you have in the publicationTarget some path on D drive while in the deployer conf you have another one from C drive). Then you also need make sure that your deployer is initialized. You can easily determine if your deployer is initialized by looking if the meta.xml is regenerated in the deployer incoming folder.
Not sure if this is relavant but you might be interested also in how to install the deployer: as a .NET WebSite, as a Java WebSite or Windows Service
Hope this helps.
You say your working sites use HTTP sender/deployer. In that scenario your deployer is triggered by the HTTP servlet which receives the transport package.
When you use local file system - you MUST configure your deployer to work in a different way. It has to run as some form of background service. Typically on a windows box this means installing the deployer as a windows service. Keep in mind that this will then probably have additional config files for the deployer and broker/storage.