General discussion about Chef

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


Chronological Thread 
  • From: Christopher Brown < >
  • To: " " < >
  • Subject: [chef] Re: Re: Bring up the discussion for knife-ec2 --node-name-prefix option
  • Date: Wed, 24 Oct 2012 16:50:35 +0000
  • Accept-language: en-US
This misses the point in exactly the same way it missed the point when we had this conversation at Amazon 8 years ago.
The point is not to have humans trying to track and use serial numbers directly, as if we were good at that.  We are not.

The point is to use an appropriate mapping when and where possible. (As you said "then tooling needs to improve to the point where I don't need to see the serial numbers").  We keep deflecting.  Hostname arguments are a symptom and are neither the actual problem nor the cure.  It's also not about being "neutral"; it's about being amenable to either concern.  If manipulating hostnames, at some scale, is part of a current process, we should not make that difficult.  We should also make rich mapping easy and first-class at scale.

-C



I've used fairly lightweight human readable hostnames for a long time now, at very large scales and while there's issues with that approach, i've seen silliness at the level of a hundred or so nodes where people who need to talk about a specific server start abbreviating the random number digits based on fractions of the hostname and i've become tired of using search and copy and pasting random numbers around.  If serial numbers is really the wave of the future then tooling needs to improve to the point where I don't need to see the serial numbers, and right now that simply isn't the state that we're in, and I'd vastly prefer to be oncall at 3am in the morning and be able to say "i'm going to reboot foo07" rather than "i'm going to reboot 8df34c1185d".  While its nice to think that humans being involved in the whole process is dirty and unclean and a symptom of a problem and we should just automate them all away, I think its drinking the kool aid way too hard.  Human names have many benefits, in addition to their downsides, and there is simply no clear winner in this argument.

IMO chef should be perfectly neutral about this issue.

On 10/22/12 7:16 AM, Christopher Brown wrote:
" type="cite">
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



Well, I'm not using ec2 but reading this thread at this point makes 2 or 3 points in my mind:


1) I'm promoting chef, at this stage I really can't tell others to stop using manually defined machine names without shooting a bullet in chef future.

2) We do use others tools (really ? yes) wich are not so easy to connect to chef, basing a decision on system name about OS/type could be easiest.


So well, it could be a "best practice" to have not meaningfull node names, but that could be helpfull too in some cases.

I see not point avoiding this kind of use for mid-way teams. But I acn see the point having this feature to help mid-way teams migrate from one step to the next...

 

So, sorry but this time some 'great' people from this list sounds elitist on how you may/should use chef ...

 

Cheers

 

Le 2012-10-22 08:45, AJ Christensen a écrit :

I'm going to go ahead and say yeah, I am Iron Man, and we are so done in this thread.

Ship the code. Resolve the ticket. Let the community use it if they want. You can give machines friendly human snowflake pet names if you like. We will not.

--AJ

On Oct 22, 2012 3:56 PM, "Sascha Bates" < "> > wrote:
With Jenkins, there are tools to copy workspaces from one job to another, to copy workspace data from one system to another, to archive artifacts, etc....  You should be making use of those kinds of tools so that you never need to go out to a specific slave to find out what went wrong with a given job.

And if we lived in a perfect world, I'm sure we'd never need to ssh anywhere and could just sit in the middle of an interactive matrix like Tony Stark.  Regardless, this is an active development environment and we are in and out of Jenkins slaves and development team VMs, and just generally being the diagnostic fixit guys.  The information doesn't always come to you. Sometimes you have to go to the information. And while I get a lot of information from the Jenkins GUI, sometimes there's no substitute for going out and looking at something.

Also, the decision was made (before I came along) to have all the dev teams use their own chef servers, so there is no unified environment in dev.  Don't get me started on the discrepancies between this arena and other environments. I'm hoping to move toward homogenization.  But we have hundreds of developers, and something like 50 Openstack tenants (all dev teams). The infrastructure started small with a couple of teams and then grew to include a large portion of the enterprise rather quickly. 

Or possibly I'm the only person who doesn't work in a perfect world. Everyone else, back to your regularly scheduled Ironman Matrix.
 
Sascha Bates | "> | 612 850 0444 | | |
On 10/21/12 7:57 PM, Brad Knowles wrote:
On Oct 21, 2012, at 5:35 PM, Sascha Bates 
 
 "><
 > wrote:


How are people working with these servers that have no useful labels?  I really want to know.  We ssh all over the place in our infrastructure and if I had to go out and look up a special snowflake ec2-blah-blah or IP every time I wanted to get to a server, I'd probably take a baseball bat to my infrastructure.

IMO, if you're manually ssh'ing around in a large infrastructure, you're doing it wrong.

If you've got a small infrastructure, and you can keep all the hostnames in your head at the same time, and you can manage your IP address space with simple /etc/hosts files, then manually ssh'ing around may be required on occasion and is probably okay.

However, if you've got a larger infrastructure, then you should have better tools to get the information you need and put it in a place where you can get to it, without you having to manually ssh around.  Those tools might end up having to use ssh to get the information, but that part of the process should be hidden from you.


For example, we run a Jenkins setup with 20 slaves.  The slaves are rebuilt often using openstack and chef.  I'm currently writing a knife plugin to set up ssh aliases for nodes in a role that make it easy for us to do things like 'ssh slave20' as we are constantly helping people figure out stuff about their jobs on the slaves or diagnosing VM issues (I'd actually really like to take a baseball bat to our Openstack infra).

With Jenkins, there are tools to copy workspaces from one job to another, to copy workspace data from one system to another, to archive artifacts, etc....  You should be making use of those kinds of tools so that you never need to go out to a specific slave to find out what went wrong with a given job.

--
Brad Knowles 
 
 "><
 >
LinkedIn Profile: <http://tinyurl.com/y8kpxu>

 

 

Archive powered by MHonArc 2.6.16.

§