|
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
From: Tensibai <
">
>
Reply-To: "
">
"
<
">
>
Date: Monday, October
22, 2012 5:38 AM
To: "
">
"
<
">
>
Subject: [chef] Re: ***
PROBABLY SPAM *** Re: Re: Re: Bring up the discussion for
knife-ec2 --node-name-prefix option
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>
|