[chef] Re: Unexpected Knife behavior and messages


Chronological Thread 
  • From: Jonathan Matthews < >
  • To:
  • Subject: [chef] Re: Unexpected Knife behavior and messages
  • Date: Wed, 6 Apr 2011 11:15:33 +0100
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=jpluscplusm.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=cd7A3bdPb/oqNJ+5QhZCpZZUMW+sjpPIxy+jJGOB91gMoRwLbEKN9Kpa7TGEnbEwY5 pLs7wLSMayQgLD9JLoKm6meGnWftOl0KPCdEKzlnkm+gnsFtx8LYp+xmMTLDmfo/z1u1 kN1Hh/ecA3L2S93Y7wfjD0TBTtqxitdLI1yKA=

On 6 April 2011 09:40, Hedge Hog 
< >
 wrote:
> Hi,
> Not sure if this is a bug, or a feature, but in my experience it is
> undesirable behavior:
>
> Given a Client "monitor" exists
> When you run `knife client create monitor --no-editor --admin --file
> /tmp/monitor/.chef/monitor.pem`
> Then the output contains:
>       """
>       INFO: Created (or updated) client[monitor]
>       """
>  And the file "/tmp/monitor/.chef/monitor.pem" contains nothing
>
> I think it is better that the file pem not be created at all.

Agreed (but I think you'll find it contains "nil" rather than being
empty - which is an annoyance in its own right!). Blatting the file
isn't the right thing to do here IMHO. Much better it should leave the
file alone entirely unless it would produce useful content. If people
/really/ want to overwrite it, they can always "knife client create >
file" unconditionally.

> And
> rather than the current INFO, a WARN message be issued:
> WARN: Conflict. client[monitor] already exists

I don't think that's right.  "client create" differs from "client
reregister" rather nicely, in that one can run "client create"
repeatedly and /not/ invalidate the private key if it exists. I do
this in some rather hacky scripts inside cobbler to push a client key
down to a machine during kickstart. It would be annoying for this
behaviour-as-designed to assume that the 2nd and subsequent
invocations for a username really /should/ produce a public key. I
don't think that's a reasonable assumption.

> This warn message is consistent with the HTTP message that knife sees,
> but somewhere along the way in knife it gets 'cured'

Yeah, but that's conceptually the same thing that happens when
creating new roles or nodes. You don't expect the 404 the server
generates there to be passed through to the end user - it's just using
HTTP response codes as a communication mechanism; they don't need to
mean (and have visibility) the same as in normal web browsing. IMHO.

Jonathan
-- 
Jonathan Matthews
London, UK
http://www.jpluscplusm.com/contact.html



Archive powered by MHonArc 2.6.16.

§