Unexpected Knife behavior and messages

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. And
rather than the current INFO, a WARN message be issued:
WARN: Conflict. client[monitor] already exists

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

HTH

πόλλ’ οἶδ ἀλώπηξ, ἀλλ’ ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com

On 6 April 2011 09:40, Hedge Hog hedgehogshiatus@gmail.com 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