[chef] Re: Re: Bring up the discussion for knife-ec2 --node-name-prefix option

[Daniel DeLeo < >]

On Monday, October 22, 2012 at 7:16 AM, Christopher Brown wrote:

Tensibai (and others who started the thread),

These are good points.  As it is with many things in this industry, one size does not fit all.

I've be responsible for very large infrastructure deployments and have argued for most of my career against spending time and energy on a naming scheme. In a large infrastructure, relying on decipherable hostnames generally means other non-scalable practices follow, exactly because you are thinking at the single host level.

Nonetheless, we (Chef users and web-scale administrators) are quick to jump on the "SCALE IS KING" bandwagon and expect those techniques to be absolute truth.  They are not.  If your infrastructure is manageable now, is not expected to grow dramatically, and you are working with other tools and existing processes, don't let other people tell you they know your business best.  Most of us are on a path of change and, over time, you may find you adopt these techniques when it's necessary or reasonable.

Until then, keep asking how Chef can help with what you do now, and what you want to do later.

-C

-- 

Christopher Brown

Chief Technology Officer, Opscode

Twitter: @skeptomai

I'd like to understand what in particular makes the node name so important.

As has been mentioned previously in this thread, any extra data about a node that you need to reference can be stored as node attributes, or inferred from the run_list. You can find and ssh into boxes with `knife search` and `knife ssh`, and list attributes with the `-a` option to search and show commands.

However, it seems that this isn't working well enough for a fair number of people. Is this because it's unwieldy or inconvenient to get at this information via knife, or that it's difficult to work this way through the webui, or something else?

As Chris implied, part of the chef philosophy is that you should get value from chef without first having to accept a bunch of absolute and inflexible axioms about the best way to model your infrastructure. At the same time, there should be an easy path towards doing things the "right" way.

So, if this feature request is actually a symptom of a deeper problem with the way Chef's UIs communicate information about your infrastructure, I'd rather fix that problem than bake a workaround into the code. Contrarily, if people really just need more flexibility in how node names get generated when using public clouds, then it makes sense to add that to the relevant knife plugins.

-- 

Daniel DeLeo