Member since
10-28-2014
71
Posts
11
Kudos Received
15
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
2951 | 07-19-2019 01:53 PM | |
16557 | 07-19-2019 12:17 PM | |
16571 | 07-19-2019 11:23 AM | |
2302 | 07-15-2019 09:40 AM | |
1389 | 04-04-2019 03:03 PM |
06-20-2018
12:47 PM
I'm glad you figured this out. There are some other places you can look for information about provider-specific configuration properties as well. There are reference configuration files here: https://github.com/cloudera/director-scripts/tree/master/configs From the help menu in the Director UI, you can access the API console, and the provider-metadata endpoints there will show you all the valid provider-specific configuration properties. If you're comfortable reading code, the plugins that enable Director to work with multiple cloud providers are open source. If you search those repositories for ConfigurationPropertyToken, you will see the classes that define the metadata for the provider-specific configuration properties. The AWS repository, for example, is here: https://github.com/cloudera/director-aws-plugin/tree/v2
... View more
03-29-2018
03:16 AM
Sorry to drag up an old topic but I am hoping there is now some official guidance from Cloudera - or perhaps a reference architecture. As soon as an organisation builds a Cloudera EDH cluster in one Amazon AWS region (or Azure or Google Cloud, or whatever) then they soon realise they might want another cluster in a different region or a different Availability Zone. Personally I am happy sticking with one Region but multiple AZs - so I am thinking that I want one Cloudera Director, one Cloudera Manager, and separate clusters in each AZ.
... View more
11-20-2017
11:46 AM
I found another post which mentioned the Crash console and cluster reconcile. After performing the steps mentioned in that post, Clouder Director was finally synchronized with my cluster and reported the correct parcel version - afterwhich I was able to deploy addtional worker nodes.
... View more
11-20-2017
11:39 AM
Reconciling the cluster using the Crash console got things back in sync for me. See the following post: https://community.cloudera.com/t5/Cloudera-Director-Cloud-based/Director-pipeline-SUSPENDED-UPDATE-FAILED/td-p/28598/page/3
... View more
11-07-2017
03:48 PM
Hi Vivek, Glad to hear! Feel free to open up another thread if you run into anything else along the way.
... View more
10-04-2017
04:23 PM
Yes I was. I deleted the Name Tag and the bootstrap kept failing, the log showed CD was trying to connect constantly to the Manager so I checked Security Group config and allowed all trafic from within the Security group. They are both configured in the same VPC, Subnet and under the same SG. Thanks for your help!
... View more
04-13-2017
09:09 AM
Yoga, I just tried to repro your problem and I see a BYON-specific instance template popup. One thing to note that may be confusing you is that Director requires an Type and Image field even though these concepts are not needed in BYON. Feel free to put anything you want in those fields. If you click on the "Advanced Options", you can specify the preferred hosts for that template. Director will attempt to pick a host from that list on a best effort basis. David
... View more
11-08-2016
02:46 PM
I experienced this issue when setting the parameter associatePublicIpAddresses: false The default seems to be 'true'. The notes for this parameter say ... # Whether to associate a public IP address with instances or not. If this is false # we expect instances to be able to access the internet using a NAT instance # # Currently the only way to get optimal S3 data transfer performance is to assign # public IP addresses to your instances and not use NAT (public subnet type of setup) # # See: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-ip-addressing.html So it makes sense that if you attempt to set this parameter to false that you may need to configure NAT as mentioned above.
... View more
09-16-2016
01:23 PM
That helped. It works now. We had no reason to expect that the instance and instances clauses were necessary for a CM that already exists and was generated by Cloudera Director.
... View more
08-25-2016
10:44 AM
3 Kudos
Due to a bug, the UI is displaying only properties marked as sensitive, despite the fact that other properties are required. As a workaround, you can use the API console to update the credentials. Go to the Environments section of the API console. Open the Get /api/v5/environments section, and click Try it out! to list the environments. Copy the environment name for the environment in which you want to update the credentials. Open the Get /api/v5/environments/{name} section, paste the environment name into the name parameter box, and click Try it out! to display the environment. Copy the config block of the JSON (should have keys like tenantId, etc.). You only want the curly braces and content, not the "config": key. Open the Put /api/v5/environments/{name}/provider/credentials section, paste the JSON block, remove the line containing the region (*see below for an explanation), and replace the REDACTED value of clientSecret with the new value. Click Try it out! to update the credentials. On success, you should get a 202 response code. For other response codes, check the error message and look in the Director server log if necessary. * The region key is not a credentials configuration key. You can see all the valid credentials configuration keys by opening the provider-metadata section of the API console, opening the Get /api/v5/metadata/providers/{providerId} section, entering azure in the providerId parameter box, clicking Try it out! to list the metadata, and finding the credentialsProperties JSON block. The configKey field of the entries in there are the valid credentials property configuration keys.
... View more
- « Previous
-
- 1
- 2
- Next »