Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Bootstrap of cluster fails due to attempt to use parcel version not specified in config

avatar
Rising Star

Using Director 2.6 and remote-bootstrap to launch clusters.  I'ved used this same config to launch several clusters so far,  but ran into a failure today. 

 

From the application.log on the Director server:

 

clusters com.cloudera.launchpad.bootstrap.cluster.UnboundedWaitForParcelStage - c.c.l.pipeline.util.PipelineRunner: Attempt to execute job failed
com.cloudera.api.ext.ClouderaManagerException: API call to Cloudera Manager failed. Method=ParcelResource.readParcel. Response Status Code: 404. Message: {
"message" : "Parcel for product 'CDH' and version '5.13.0-1.cdh5.13.0.p0.29' is not found in cluster 'Development'."

 

In my client config, I'm specifying the cdh parcel version like so:

 

 

parcelRepositories: ["https://archive.cloudera.com/cdh5/parcels/5.13/",

Why is the install looking for a parcel version under parcels/5.13.0/ instead of what I've specified above?  I would expect that specifiying "parcels/5.13/" in the URL would result in the latest version of 5.13 - which in this case would be 5.13.1-x

 

See:

https://archive.cloudera.com/cdh5/parcels/5.13.0/

vs.

https://archive.cloudera.com/cdh5/parcels/5.13/

1 ACCEPTED SOLUTION

avatar
Rising Star

Is this reproducible? Director does cache some of the parcel repository information but it gets cleared at the beginning of bootstrap so that shouldn't be the problem. You can also try restarting Director (which also clears the cache) just to make sure.

View solution in original post

2 REPLIES 2

avatar
Rising Star

Is this reproducible? Director does cache some of the parcel repository information but it gets cleared at the beginning of bootstrap so that shouldn't be the problem. You can also try restarting Director (which also clears the cache) just to make sure.

avatar
Rising Star

Hi.  Thank you for your response.

 

This was reproducible, but a restart of Cloudera Director service resolved the issue.