There's no need to apologize in my case :)
I just wanted to point out some use cases where it's not trivial to bind chef and another tool which have a built-in capability to make decision based on node names ...
For a quick exemple here, our antivirus guess the OS (linux/windows) based on a node name filter (just to know how it should connect to it).
Indeed I may try to replace that with an API call, but it will probably takes me quite long just to guess if I really can and this is time I won't spend on recipes to do things we have to do manually for now. That's why I do think we're not ready to forget our anming scheme and still need to enforce it on new servers to keep existing running smoothly.
Tensibai
Le 2012-10-22 18:54, AJ Christensen a écrit :
Tensibai, others;
I'd like to apologize for the late night post-rant final reply here.
It was not my intention to come across as elitist, and I hope you and the community can forgive me. I stepped over the line. Trying to speak from experience without relaying the full context often causes this problem for me. I got annoyed and banged out a dumb reply.
As Chris and Dan have pointed out, there are a few issues at hand here and I am sure that Chef will continue to be flexible in this matter. I personally prescribe to CB's methodology re: not spending time building naming schemes.
If there is one final commentary I can make: I'd highly advise against reflecting on node names as meta data for any kind of recipe flow. I would however recommend ensuring you have appropriate systems that allow for consistent machine identification and address resolution, and generally speaking; I think the node name is an appropriate source of data for that case although any similar data would do.
Deepest apologies,
AJ
On Oct 23, 2012 1:39 AM, "Tensibai" < "> > wrote:
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.