Member since
09-30-2015
26
Posts
11
Kudos Received
4
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1120 | 09-01-2016 07:50 AM | |
7595 | 04-21-2016 12:29 PM | |
1422 | 04-08-2016 06:59 AM | |
614 | 12-02-2015 03:49 PM |
10-26-2017
12:45 PM
2 Kudos
Hi @Rajkamal Mahamuni Natarajan, Cloudbreak artifacts are published to an older sequenceiq maven repo on S3, e.g. the artifact of the 1.16.4 release is here: https://s3-eu-west-1.amazonaws.com/maven.sequenceiq.com/releases/com/sequenceiq/cloudbreak/1.16.4/cloudbreak-1.16.4.jar It is a Spring Boot package, so module JARs are packaged inside. Marton
... View more
05-04-2017
12:06 PM
Okay, we'll need to see the Cloudbreak logs. You can get it by ssh-ing to the controller machine and get it with the command: "cbd logs cloudbreak". You can also check the autoscaling tab on the EC2 console (Scaling history) and check if the VMs are available and healthy. @cduby @DL
... View more
05-03-2017
03:37 PM
@cduby @DL If you're using spot instances, can you try to increase the bid price, or without spot instances first? I can see on the screenshots that infrastructure creation is taking more than an hour (it should be around 5 mins with on-demand instances, and a few mins more with spot priced instances). You can try to check the spot requests page and see if there are any messages there, like "request is pending". So the main problem is that infra creation is taking too much time and that's why the temporary credentials used by HDC are expired - it is still a bug because spot instance requests can sometimes take more than an hour to fulfill and HDC should be able to handle that. But for now as a workaround you should find out what is taking too long (my guess is spot requests), and change the cluster configuration according to that - different instance types, bid price, etc..
... View more
01-27-2017
09:56 AM
@ikawana "The maximum number of addresses has been reached" means that you've reached your quota of Elastic IPs on AWS. That is probably because you did not delete your CloudFormation stacks and have a few AWS resources stuck. You can terminate your clusters from the Cloudbreak UI - that deletes all the resources from AWS even if the cluster create failed before. If you don't want to attach the full logs here you can send it to me via email (msereg hortonworks com), or please find the part with the original error message: ("Cluster installation failed to complete, please check the Ambari UI for more details") and attach the context of that - the previous messages that lead to the error message.
... View more
01-26-2017
04:30 PM
@Muji can you see an exception stacktrace, or only this message? can you send me the full cloudbreak logs? There should be an earlier exception related to the infrastructure creation, because this error message means that the backend couldn't trigger the HDP installation (cluster in CB terminology) flow because the underlying infrastructure (stack in CB terminology) is not ready.
... View more
01-26-2017
11:11 AM
@ikawana the first exception is about a default blueprint cannot be found. It is caused by an improperly set default value, but it won't cause an issue. the second exception shouldn't cause this kind of failure either. So rather please provide me the following things: - cbd/cloudbreak version and where is it deployed (locally, on aws, etc) - please attach the full cloudbreak logs (docker logs -f cbreak_cloudbreak_1) - are you trying to deploy the cluster with the default network settings that create a new VPC for the cluster? - if this error message happens, you should already see your VMs running on EC2. Can you see those VMs in "running" state on the AWS console? Can you SSH to those instances? If yes do you see ambari-server running on the instance? What is the output of `sudo ambari-server status`?
... View more
01-25-2017
12:28 PM
@ikawanaThe first 2 log messages only show that the backend couldn't send push notifications to the UI, so you may need to refresh the page to see changes, but that won't cause any errors on the backend. Based on the cluster status, it seems that the instance was successfully started on AWS and the ambari-agent was started as well, but the blueprint installation couldn't be finished. Can you send us the cloudbreak logs that contain this error message? "Cluster installation failed to complete..." And if you click on the cluster on the Cloudbreak UI, can you see the Ambari address displayed? If not can you reach the Ambari server web UI by going to https://<public-ip-of-ambari-node>/ambari?
... View more
01-25-2017
10:13 AM
1 Kudo
@Joginder Sethi can you SSH to the control plane VM and send me the logs from: - /var/log/cbd-quick-start.log - the output of the "docker logs cbreak_cloudbreak_1" command I've seen this error message once when the SSH public key that was selected on the CFN create stack page had a length shorter than 2048. Please check if your public key's length is at least 2048 because only those are supported by HDC.
... View more
09-01-2016
07:58 AM
Cloudbreak 1.4.0 can deploy HDP 2.5, see my other answer here: https://community.hortonworks.com/questions/54346/which-version-of-cloudbreak-is-the-latest-123-or-1.html You can also look into "Hortonworks Data Cloud" that's an AWS only solution built on top of Cloudbreak with a simplified UI and with the capability to deploy 2.5: http://hortonworks.github.io/hdp-aws/
... View more
09-01-2016
07:50 AM
3 Kudos
Cloudbreak 1.3 is a technical preview because there was a big change in the underlying infrastructure: we got rid of docker containers completely in the cluster, so from 1.3, HDP services run directly on the VMs. In Cloudbreak 1.3 there are some missing features that were not following this big change immediately but we wanted to release a "dockerless" version as soon as possible. Since then there is already Cloudbreak 1.4 which is still considered a technical preview but I would suggest to use it instead of 1.2.3, until 2.0 is out. You can grab 1.4.0 with this curl command: curl -LsO s3.amazonaws.com/public-repo-1.hortonworks.com/HDP/cloudbreak/cloudbreak-deployer_1.4.0_$(uname)_x86_64.tgz Or you can update an existing deployment with these commands: cbd kill
cbd update rc-1.4
cbd regenerate
cbd start
... View more
04-25-2016
02:10 PM
@Arthur GREVIN Please check the logs of your UI container with docker logs cbreak_uluwatu_1
And please also send me the cloudbreak logs in email to msereg at hortonworks com. I'm not sure about this issue but maybe we can setup a webex tomorrow, it would be simpler I think.
... View more
04-25-2016
11:30 AM
@Arthur GREVIN Can you check the developers console in your browser and see if there is a JS error there? There was a bug in that version of cloudbreak that caused this sometimes on first page load but it ususally loads successfully after a few page refreshes. This bug was fixed later, but there is no official release that contains it yet. If this error doesn't disappear, you can try to update the cloudbreak-web container with a patch like this: Add this line to your cbd Profile: export DOCKER_TAG_ULUWATU=1.2.5-rc.5 and run these commands to regenerate the yml files and restart cbd: cbd kill
cbd regenerate
cbd start This will pull the latest rc container of the UI where this bug is fixed and will restart all the components. (You may need to stop your dev cloudbreak and run the local-dev command again)
... View more
04-22-2016
09:29 AM
It should be a container from image hortonworks/cloudbreak-web:1.2.3 named cbreak_uluwatu_1. Can you see it with docker ps -a as terminated? If yes can you send me the logs, or try to restart it with docker restart cbreak_uluwatu_1?
... View more
04-22-2016
09:05 AM
@Arthur GREVIN It is the API that's running on 9091 and there is nothing mapped to /. If you're checking out a URL that is mapped to an API endpoint, like 10.0.0.30:9091/api/v1/connectors, you should see a json returned. You can try it out with other pathes as well, like /api/v1/stacks that needs authentication, it should return an "unauthorized" message. To see the api docs check out /apidocs. If you're looking for the UI, it is running in a different container that is started by cbd. It is a nodejs app and it should listen on port 3000. Did you use cbd to start cloudbreak then the cbd util local-dev command to set up a dev env?
... View more
04-21-2016
03:06 PM
@Arthur GREVIN it is expected behavior, gradle doesn't put the process in the background, but Cloudbreak is started correctly. Technically the gradle process is running until Cloudbreak is stopped that's why it doesn't show 100%. You can put it in the background just like any other processes.
... View more
04-21-2016
12:29 PM
1 Kudo
Hi @Arthur GREVIN If you'd like to use the bootRun command make sure you are running it against the build.gradle in the core module like this (the properties file only works with an absolute path for me): ./gradlew bootRun -Dspring.config.location=file:/Users/msereg/prj/cloudbreak/core/app.properties --stacktrace -b core/build.gradle If permgen space runs out of memory include this line in the core/build.gradle file: bootRun { jvmArgs = ["-XX:MaxPermSize=256m"] ...} Also if you have connection issues like above it means that your other containers are not running with cbd, or you have specified a wrong IP address for your docker-machine. You can check it out with this command: docker-machine env <your-machine's-name> For example mine is 192.168.99.100, I'm using this instead of 192.168.59.103 that's in the example. , If you'd like to use the bootRun command make sure you are running it against the build.gradle in the core module like this (the properties file only works with an absolute path for me): ./gradlew bootRun -Dspring.config.location=file:/Users/msereg/prj/cloudbreak/core/app.properties --stacktrace -b core/build.gradle If permgen space runs out of memory include this line in the core/build.gradle file: bootRun { jvmArgs = ["-XX:MaxPermSize=256m"] ...} Also if you have connection issues like above it means that your other containers are not running with cbd, or you have specified a wrong IP address for your docker-machine. You can check it out with this command: docker-machine env <your-machine's-name> For example mine is 192.168.99.100, I'm using this instead of 192.168.59.103 that's in the example.
... View more
04-08-2016
04:45 PM
1 Kudo
I think it should be 9090 or 8080 then, I've copied it from my dev env and it's 9091 there.
... View more
04-08-2016
06:59 AM
1 Kudo
Hi, Cloudbreak's authentication is standard OAuth2 and it is provided by UAA (https://github.com/cloudfoundry/uaa). So you must first obtain a token from the UAA identity server, running in a 2. docker container with cbd and then send this token to the Cloudbreak resource server in every API request. There are different types of client applications for an OAuth2 resource server, Cloudbreak has 2 implemented clients, a CLI and the web UI. The webUI uses the standard "authorization code" flow, while the CLI uses the much simpler "implicit grant" flow. So first you should decide which flow you'd like to use. Are you developing a web app, or some kind of CLI? The implicit grant token request can be done with a simple curl for example (cloudbreak_shell is a registered application in the UAA db, you may want to add a new application there): export TOKEN=$(curl -iX POST -H "accept: application/x-www-form-urlencoded" -d 'credentials={"username":"admin@example.com","password":"<password>"}' "http://<cloudbreak-url>:8089/oauth/authorize?response_type=token&client_id=cloudbreak_shell&scope.0=openid&source=login&redirect_uri=http://cloudbreak.shell" | grep Location | cut -d'=' -f 3 | cut -d'&' -f 1) After you have a token (that's the hard part), you should send that token to Cloudbreak in every request header like this: curl -X DELETE -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" http://localhost:9091/api/v1/stacks/44/cluster
For an authorization grant flow example you can check out the webUI, especially these lines in the nodejs code: https://github.com/sequenceiq/cloudbreak/blob/master/web/server.js#L217 https://github.com/sequenceiq/cloudbreak/blob/master/web/server.js#L179 Marton
... View more
12-02-2015
03:49 PM
2 Kudos
Hi, We've deployed the 1.1-rc version of Cloudbreak to the hosted environment, where the Azure implementation is completely rewritten to support the new ARM API of Azure. It is faster and more reliable but it doesn't work with the old Azure credentials. You should create a new Azure credential as described here, and try to create the cluster with the new credential.
... View more
11-02-2015
04:52 PM
Hi, you mean something like Amazon's EC2 Container Service? (http://aws.amazon.com/documentation/ecs/)
... View more