Support Questions

Find answers, ask questions, and share your expertise

ClouderaDirector 2.2.0 failed with local-repository: NoSuchElementException

avatar
Expert Contributor

Localrepo synced latest version from:

- ClouderaDirector

- ClouderaManager

 

Also serving parcels:

- CDH

- spark2

 

Bootstrap config:

cloudera-manager {
...
repository: "http://localrepo/cloudera-manager/"
repositoryKeyUrl: "http://localrepo/cloudera-manager/RPM-GPG-KEY-cloudera"
}

...
cluster {
products {
CDH: 5
}

parcelRepositories: ["http://localrepo/parcels/cdh5/", "http://localrepo/parcels/spark2/"]
...
}

 

We start with cloudera-director-client bootstrap-remote with the config file.

The ClouderaDirector provisioning: ClouderaManager, datanodes, masters are created. But script failes at around step 870/900.

 

No errors in ClouderaManager logs, error appears in ClouderaDirector log, getting something from an empty-collection when building some Repo-list.

 

Bootstrap remote with a config file end with failed state:

/var/log/cloudera-director-server/application.log

 

 

[2016-12-13 10:00:53] INFO  [pipeline-thread-31] - c.c.l.pipeline.util.PipelineRunner: >> BootstrapClouderaManagerAgent$HostInstall/4 [DeploymentContext{environment=Environment{n
ame='DataLake-devtst', provider=InstanceProviderConfig{t ...
[2016-12-13 10:00:53] ERROR [pipeline-thread-31] - c.c.l.pipeline.util.PipelineRunner: Attempt to execute job failed
java.util.NoSuchElementException: null
        at com.google.common.collect.AbstractIterator.next(AbstractIterator.java:154)
        at com.google.common.collect.Iterators.getOnlyElement(Iterators.java:307)
        at com.google.common.collect.Iterables.getOnlyElement(Iterables.java:284)
        at com.cloudera.launchpad.bootstrap.cluster.BootstrapClouderaManagerAgent.getRepoUrl(BootstrapClouderaManagerAgent.java:325)
        at com.cloudera.launchpad.bootstrap.cluster.BootstrapClouderaManagerAgent.newApiHostInstallArguments(BootstrapClouderaManagerAgent.java:307)
        at com.cloudera.launchpad.bootstrap.cluster.BootstrapClouderaManagerAgent.access$200(BootstrapClouderaManagerAgent.java:63)
        at com.cloudera.launchpad.bootstrap.cluster.BootstrapClouderaManagerAgent$HostInstall.run(BootstrapClouderaManagerAgent.java:162)
        at com.cloudera.launchpad.bootstrap.cluster.BootstrapClouderaManagerAgent$HostInstall.run(BootstrapClouderaManagerAgent.java:112)

 

Is this a bug? Or am I doing somthing wrong?

 

Local repo looks like this, and works fine for installing ClouderaDirector:

[root@localrepo mirror]# ls -ARls | grep /
./cloudera-director:
./cloudera-director/repodata:
./cloudera-director/RPMS:
./cloudera-director/RPMS/x86_64:
./cloudera-director/RPMS/x86_64/repodata:
./cloudera-manager:
./cloudera-manager/repodata:
./cloudera-manager/RPMS:
./cloudera-manager/RPMS/x86_64:
./cloudera-manager/RPMS/x86_64/repodata:
./parcels:
./parcels/cdh5:
./parcels/spark2:

 

1 ACCEPTED SOLUTION

avatar
Expert Contributor

When I used the FullyQualifiedDomainName (with a '.' in it) the repo is working fine!

 

 parcelRepositories: ["http://localrepo.cdh-cluster.internal/parcels/cdh5/", "http://localrepo.cdh-cluster.internal/parcels/spark2/"]

View solution in original post

3 REPLIES 3

avatar
Super Collaborator

Hi MrBee,

 

Congratulations, you found a bug in Director! 🙂

 

I believe the problem is that the hostname "localrepo" is rejected by the URL validator. I recommend using a hostname with a short (2-4 character) domain component, for example, "localrepo.com", to see if that passes the validation.

 

In the meantime, I'll file a bug report for this so we can loosen the validation properly.

 

Thanks for your post, and sorry for the inconvenience!

 

Bill

avatar
Expert Contributor
I’ll try that out this week. And let you know!
Thx for your advice.

avatar
Expert Contributor

When I used the FullyQualifiedDomainName (with a '.' in it) the repo is working fine!

 

 parcelRepositories: ["http://localrepo.cdh-cluster.internal/parcels/cdh5/", "http://localrepo.cdh-cluster.internal/parcels/spark2/"]