[chef] Re: Re: 400 bad request


Chronological Thread 
  • From: Daniel DeLeo < >
  • To: Michael Pereira < >
  • Cc:
  • Subject: [chef] Re: Re: 400 bad request
  • Date: Mon, 10 Aug 2015 12:00:30 -0700

On Monday, August 10, 2015 at 11:20 AM, Michael Pereira wrote:
> >  
> > From this stack trace, it looks like you’re re-using a client/node name 
> > that already exists on the server. Some recent changes to the API have 
> > made this raise a different error than it used to, but it wouldn’t have 
> > worked before. The best way to deal with this is to delete the 
> > "client-machine” client and node on the server before you bootstrap a new 
> > one.
> >  
> > We will look at making a change to have this produce a clearer error (I 
> > think the error message was much better in the past).
> You're right, good catch from the minimal stack trace! I managed to find 
> the correct error in the long debug output :
>  
> > [2015-08-10T13:51:53-04:00] DEBUG: ---- HTTP Response Body ----
> > [2015-08-10T13:51:53-04:00] DEBUG: {"error":["Client already exists"]}
> > [2015-08-10T13:51:53-04:00] DEBUG: ---- End HTTP Response Body -----
>  
>  
> Now the interesting part is that this node does not show up in the knife 
> node list command output. I removed the chef-client rpm and delete the 
> content under /etc/chef/ before trying to use the cloned machine with chef 
> but I'm not sure if it is not picking up the original machine private key 
> from somewhere else and sending it to the server.
Each machine you manage generally has two corresponding objects on the 
server. One is the node, which as you know is the data about that machine’s 
state and so on. The other part is the client, which is more or less an “API 
key” object (kind of like a user account, but doesn’t have a password and can 
only be a part of one organization). When you remove an old node, you should 
delete both of these things (e.g., `knife client delete client-machine`).
  
>  
> Regards,
> Michael
>  

HTH,

--  
Daniel DeLeo






Archive powered by MHonArc 2.6.16.

§