The script I suggested you use is just an automated version of the process documented at the link you provided. I would just try running the script, and when that's done going back and retrying the Phoenix parcel. ... View more

It's a button on the desktop in the QuickStart VM - I saw you were using Docker, so I added the CLI equivalent of 'sudo /home/cloudera/parcels' above <- that should run the same script that will install the parcel that matches the QuickStart image, remove the Linux packages, etc.. ... View more

Via CLI, that script can be invoked as `sudo /home/cloudera/parcels`. ... View more

The reason is that you can't mix a Linux packages install with a parcels install. By default, the VM uses Linux packages so that you don't have to use CM unless you have the memory. There's a button on the desktop to migrate CDH to a parcel installation. After you've run that, the Phoenix parcel install should work. ... View more

I'm not sure this question is referring to the QuickStart VM. CM is already installed, it's just not started by default and you need to use the provided scripts to switch to a CM-based deployment. This question is referring to the CM installer. I'm not surprised it would fail with 1 GB of RAM but I would expect it to work with 6 GB of RAM (even though a production cluster should be on much larger machines). Have you looked at the /var/log/cloudera-manager-installer/6.start-embedded-db.log file, or is that where this is coming from? It looks like it's specifically the DB server that's failing, so other files in /var/log/cloudera-manager may be helpful. I don't recall specific names, but there's on that's clearly DB-specific, and I suspect that's where you'll find the real root cause. ... View more

So I can't tell you anything about your current formation because as I said, that access code appears to be incorrect, so I can't pull up the logs. I tried some Zoomdata deployments and did run into one issue with some operations timing out because they were trying to reach a Zoomdata package repository that no longer exists. I have fixed that problem so it shouldn't affect any new deployments. It's possible that was affecting your previous attempts, but not in the logs I've found that appear to match your forum username. So if you do try another deployment, just be sure you have a new access code that you haven't used before, and don't pause the instances prematurely. ... View more

That doesn't appear to be a valid access code and I can't find any new access codes with the same name as the ones I was looking at last week. You say you 'started up the instances' for today's session: again, restarting or stopping instances before the deployment has finished will fail, and there's no recovering from that. I started investigating the other failure that's now been seen twice during our Zoomdata deployment. I have not yet gotten to the bottom of that, so I'll still need to find out why that's happening and get back to you. Given that your current master node's progress bar is stuck on that step, it's possible you're hitting that failure again. ... View more

In either CloudFormation or your list of instances, the instance Zoomdata running on is specifically tagged. On that instance on port 8080, Zoomdata should be running. But again, Zoomdata and the data for that tutorial is one of the last things to be set up. I can look up your clusters and see more specifically what's going on, but it's much easier if you can send me a private message with the access code you used for a given attempt. ... View more

So if you restarted your instances before the deployment finished, the dpeloyment will not have finished. You may be missing datasets or some configuration in your cluster. If you didn't already read it, read the "Stopping and Starting Instances" section of the documentation, as there are some other caveats you should be aware of:   http://www.cloudera.com/get-started/cloudera-live/aws-documentation.html ... View more

Yes, you should get an email with credentials once the progress bar has completed, however even without the email you can find the credentials to the Hue and CM service in a file on the Master Node (you log into using the ssh key you selected at deployment time) in the file /var/tmp/cm_hue_admin_password.txt. Of course, usually the reason you don't get the final email is if there's a problem in the deployment, and in that case Hue and CM may not yet be set up properly. I believe I found the access codes for your 2 attempts and had a look at the logs. In one case, it looks like the machines were shutdown mid-deployment outside of our control. It did look like the transfer of the sample datasets from S3 were taking longer than usual, so I'll follow up on that and see if that can be improved or if we need to adjust the time the progress bar expects it to take. Another attempt looks like an SSH error when setting up the Zoomdata sample datasets that might also have been a shutdown of the instances outside our control, but I've seen the exact same error on another Zoomdata deployment recently so that may be a bug that I'll investigate further. I'll post back here when I have a solution deployed or a workaround to recommend for you. ... View more

Yeah you can register again with the same information and it should work. If it goes wrong again, as I said - just send me the access code and I can dig deeper. ... View more

I would double check that your access key is correct and unique for each attempt (if it's invalid, there unfortunately isn't a good way to notify you). An access key is linked to specific VMs, so they're not reusable. Also, make sure you don't reboot the instances until the initial deployment is finished. When you reboot AWS assigns you new IPs, which the cluster can deal with once it's running, but as long as you need external control (i.e. for the initial deployment) the IPs must be consistent. Anything else that depends on the user to be done correctly should result in the stack being marked as a failure in CloudFormation, so if you're pretty sure the above issues don't apply there may have been some other kind of failure we should take a look at. If you would like to send me a direct message with the access keys for your attempts I can retrieve the detailed logs for your specific case and investigate other possibilities. ... View more

In your case it looks like you need to restart hadoop-hdfs-datanode. ... View more

Yeah you're *supposed* to get the email within about 10 minutes of the cluster being green within AWS. If it takes more than 15-20 I would usually just delete the cluster and contact us. In this case there were a number of abandoned deployments (i.e. machines getting deleted mid-deployment and the system waiting to see if they come back) hogging resources. Everything that was delayed should now be running and you should receive an email momentarily if you didn't already. Thanks for letting us know about your delay - sorry for the inconvenience. ... View more

The links to the form are in the form of the 3 buttons, "Cloudera Enterprise", "Cloudera + Tableau", and "Cloudera + Zoomdata" at www.cloudera.com/live. I agree that isn't as clear as it used to be - I'll see if that can be updated soon. To answer your question, Cloudera Live AWS codes are single use, but you can register for new access codes. ... View more

Everything in CDH is set up and running without Cloudera Manager. You can complete the tutorial (although a few sections will be irrelevant and get hidden if Cloudera Manager isn't launched), and all the examples in Hue should work (Hue has an option built-in to install examples for Hive & Impala SQL queries, the HBase and Search apps, Pig scripts and more). You can also run Hadoop and Spark jobs, etc. Pretty much anything you would actually use to store and process data should work. ... View more

I'd need to take a look at a cluster and won't get a chance to for a little while, but that may not be a problem. Si I would just proceed as-is. Displaying shard replicas in the interface might no longer happen - I personally found it cluttered the interface for something I never used, so I wouldn't be surprised if that was removed recently and the screenshot in the tutorial simply needs to be updated. Also, I believe it's "step 1" that is not necessary since it's already done when installing the sample datasets (the command in #1 creates a blank configuration, we're providing the already-edited configuration). I think it's step #2 that you were missing, where that configuration gets uploaded to Zookeeper. ... View more