# Bring up the discussion for knife-ec2 --node-name-prefix option

**URL:** <https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213>\
**Category:** Chef Infra (archive)\
**Created:** [October 21, 2012, 10:21am UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213 "2012-10-21T10:21:13Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![millisami\_r](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/millisami_r/32/418_2.png) [@millisami\_r](https://discourse.chef.io/u/millisami_r)\
**Post date:** [October 21, 2012, 10:21am UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/1 "2012-10-21T10:21:13Z")

</div>

Ohai Chefs!

Last week, there was a good discussion on whether to bring the --elastic-ip attachment into the knife-ec2 and I hope that it will settle down and get release on the upcoming version.

But at this very same time, I’ld like to know and bring up the discussion on this pull req as well: [https://github.com/opscode/knife-ec2/pull/61](https://github.com/opscode/knife-ec2/pull/61)

I’m really positive about this option as well.

Want to hear about the community on this!

* * *

@millisami  
~ Sachin Sagar Rai  
Ruby on Rails Developer  
[http://tfm.com.np](http://tfm.com.np)  
[http://nepalonrails.tumblr.com](http://nepalonrails.tumblr.com)  
Sent with Sparrow ([http://www.sparrowmailapp.com/?sig](http://www.sparrowmailapp.com/?sig))

---

<div class="post-metadata">

**Author:** ![AJ\_Christensen](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/aj_christensen/32/525_2.png) [@AJ\_Christensen](https://discourse.chef.io/u/AJ_Christensen)\
**Post date:** [October 21, 2012, 4:51pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/2 "2012-10-21T16:51:40Z")

</div>

Labels are for jam jars, not machinery

--AJ  
On Oct 21, 2012 11:21 PM, "Sachin Sagar Rai" [millisami@gmail.com](mailto:millisami@gmail.com) wrote:

> Ohai Chefs!
> 
> Last week, there was a good discussion on whether to bring the  
> --elastic-ip attachment into the knife-ec2 and I hope that it will settle  
> down and get release on the upcoming version.
> 
> But at this very same time, I'ld like to know and bring up the discussion  
> on this pull req as well: [[KNIFE\_EC2-74] added new node-name-prefix option by nybble73 · Pull Request #61 · chef/knife-ec2 · GitHub](https://github.com/opscode/knife-ec2/pull/61)
> 
> I'm really positive about this option as well.
> 
> Want to hear about the community on this!
> 
> * * *
> 
> @millisami  
> ~ Sachin Sagar Rai  
> Ruby on Rails Developer  
> [http://tfm.com.np](http://tfm.com.np)  
> [http://nepalonrails.tumblr.com](http://nepalonrails.tumblr.com)  
> Sent with Sparrow [http://www.sparrowmailapp.com/?sig](http://www.sparrowmailapp.com/?sig)

---

<div class="post-metadata">

**Author:** ![John\_Dewey](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/john_dewey/32/457_2.png) [@John\_Dewey](https://discourse.chef.io/u/John_Dewey)\
**Post date:** [October 21, 2012, 4:53pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/3 "2012-10-21T16:53:48Z")

</div>

+1

On Sunday, October 21, 2012 at 9:51 AM, AJ Christensen wrote:

> Labels are for jam jars, not machinery  
> --AJ  
> On Oct 21, 2012 11:21 PM, "Sachin Sagar Rai" \<[millisami@gmail.com](mailto:millisami@gmail.com) ([mailto:millisami@gmail.com](mailto:millisami@gmail.com))\> wrote:
> 
> > Ohai Chefs!
> > 
> > Last week, there was a good discussion on whether to bring the --elastic-ip attachment into the knife-ec2 and I hope that it will settle down and get release on the upcoming version.
> > 
> > But at this very same time, I'ld like to know and bring up the discussion on this pull req as well: [[KNIFE\_EC2-74] added new node-name-prefix option by nybble73 · Pull Request #61 · chef/knife-ec2 · GitHub](https://github.com/opscode/knife-ec2/pull/61)
> > 
> > I'm really positive about this option as well.
> > 
> > Want to hear about the community on this!
> > 
> > * * *
> > 
> > @millisami  
> > ~ Sachin Sagar Rai  
> > Ruby on Rails Developer  
> > [http://tfm.com.np](http://tfm.com.np)  
> > [http://nepalonrails.tumblr.com](http://nepalonrails.tumblr.com)  
> > Sent with Sparrow ([http://www.sparrowmailapp.com/?sig](http://www.sparrowmailapp.com/?sig))

---

<div class="post-metadata">

**Author:** ![J\_Light](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/j_light/32/412_2.png) [@J\_Light](https://discourse.chef.io/u/J_Light)\
**Post date:** [October 21, 2012, 5:27pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/4 "2012-10-21T17:27:48Z")

</div>

Labels are for people who like naming things... like the whole field  
of computer scientists. All we do when it comes down to it is name  
things and refer to them by names that make sense to us to do things  
that are usually useful for some reason or another.

Why the negativity towards someone else's perception of how to name  
things usefully?

On Sun, Oct 21, 2012 at 12:53 PM, John Dewey [john@dewey.ws](mailto:john@dewey.ws) wrote:

> +1
> 
> On Sunday, October 21, 2012 at 9:51 AM, AJ Christensen wrote:
> 
> Labels are for jam jars, not machinery
> 
> --AJ
> 
> On Oct 21, 2012 11:21 PM, "Sachin Sagar Rai" [millisami@gmail.com](mailto:millisami@gmail.com) wrote:
> 
> Ohai Chefs!
> 
> Last week, there was a good discussion on whether to bring the --elastic-ip  
> attachment into the knife-ec2 and I hope that it will settle down and get  
> release on the upcoming version.
> 
> But at this very same time, I'ld like to know and bring up the discussion on  
> this pull req as well: [[KNIFE\_EC2-74] added new node-name-prefix option by nybble73 · Pull Request #61 · chef/knife-ec2 · GitHub](https://github.com/opscode/knife-ec2/pull/61)
> 
> I'm really positive about this option as well.
> 
> Want to hear about the community on this!
> 
> * * *
> 
> @millisami  
> ~ Sachin Sagar Rai  
> Ruby on Rails Developer  
> [http://tfm.com.np](http://tfm.com.np)  
> [http://nepalonrails.tumblr.com](http://nepalonrails.tumblr.com)  
> Sent with Sparrow

---

<div class="post-metadata">

**Author:** ![AJ\_Christensen](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/aj_christensen/32/525_2.png) [@AJ\_Christensen](https://discourse.chef.io/u/AJ_Christensen)\
**Post date:** [October 21, 2012, 5:49pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/5 "2012-10-21T17:49:14Z")

</div>

The machines already come with extremely useful names (ec2). Node name  
currently can be explicitly set or reflects the machine host name, instance  
ID. No?

I believe the instance ID system currently in use may have been developed  
by some sort of computer scientist. Hard to say though.

The negativity, and I'll thank you for asking, stems from the repeated  
requests over time for pretty snowflake node names of varying forms. The  
answer remains the same, so obviously one might become a little jaded.

This doesn't need to be functionality baked into 'knife-ec2'. Not only  
that, but naming / host name management, machine DNS (etc) are solved  
problems during convergence time.

I hope this clarifies my original statement and I'd like to apologize for  
the negativity, it doesn't really help.

I got 99 problems bit naming isn't one.

Cheers,

AJ  
On Oct 21, 2012 10:28 AM, "James Light" [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com) wrote:

> Labels are for people who like naming things... like the whole field  
> of computer scientists. All we do when it comes down to it is name  
> things and refer to them by names that make sense to us to do things  
> that are usually useful for some reason or another.
> 
> Why the negativity towards someone else's perception of how to name  
> things usefully?
> 
> On Sun, Oct 21, 2012 at 12:53 PM, John Dewey [john@dewey.ws](mailto:john@dewey.ws) wrote:
> 
> > +1
> > 
> > On Sunday, October 21, 2012 at 9:51 AM, AJ Christensen wrote:
> > 
> > Labels are for jam jars, not machinery
> > 
> > --AJ
> > 
> > On Oct 21, 2012 11:21 PM, "Sachin Sagar Rai" [millisami@gmail.com](mailto:millisami@gmail.com)  
> > wrote:
> > 
> > Ohai Chefs!
> > 
> > Last week, there was a good discussion on whether to bring the  
> > --elastic-ip  
> > attachment into the knife-ec2 and I hope that it will settle down and get  
> > release on the upcoming version.
> > 
> > But at this very same time, I'ld like to know and bring up the  
> > discussion on  
> > this pull req as well: [[KNIFE\_EC2-74] added new node-name-prefix option by nybble73 · Pull Request #61 · chef/knife-ec2 · GitHub](https://github.com/opscode/knife-ec2/pull/61)
> > 
> > I'm really positive about this option as well.
> > 
> > Want to hear about the community on this!
> > 
> > * * *
> > 
> > @millisami  
> > ~ Sachin Sagar Rai  
> > Ruby on Rails Developer  
> > [http://tfm.com.np](http://tfm.com.np)  
> > [http://nepalonrails.tumblr.com](http://nepalonrails.tumblr.com)  
> > Sent with Sparrow

---

<div class="post-metadata">

**Author:** ![J\_Light](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/j_light/32/412_2.png) [@J\_Light](https://discourse.chef.io/u/J_Light)\
**Post date:** [October 21, 2012, 6:27pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/6 "2012-10-21T18:27:13Z")

</div>

Okay. I may misunderstand the topic here. It sounds like you're saying  
that the i-xXxXxxwhatever-whatever-whocan-remember-any-of-this AWS EC2  
instance ID string should be good enough for everyone to use as a node  
name? Either that or they should settle for naming their nodes  
explicitly at creation time.

And I thought what the pull request in the link was asking for was a  
way to have a prefix set so that one could launch a whole formation of  
nodes and have the node names all be able to be easily matched later  
by a trivial regular expression.

If your point is that this functionality is not needed specifically in  
the EC2 plugin, I think you have a strong stance and can be shown to  
be correct.

If your point is that this functionality isn't needed for any reason  
at all anywhere, I think you are being inflexible and at least  
bordering on what seems myopic.

You don't really need this in the ec2 plugin per-se as I don't see  
this functionality being EC2-specific. Where I'm at, we already have a  
script that we call that just interactively asks for the knife options  
while suggesting the ones that we generally use to launch a base linux  
instance with no frills (which is the usual case if we're launching  
from knife), so it would be easy to add a 'Node Name Prefix' option  
and then use that for repeated knife calls. No EC2 plugin patching  
needed.

While I don't understand the orignal idea of why this needs to be an  
EC2 plugin, but I also don't understand what I interpret as implying  
that some md5-lookin hash thingmabobbyboo is a memorable name. Unique  
and useful as a unique ID in the context of dynamic generation, YES,  
but I'm a human being and sometime I'd also like to remember what the  
heck I just called one of my programmable resources so I can easily  
refer to it later.

What am I missing on both sides of this please?

\*) how is this ec2 specific?  
\*) are there any situations where it is useful to have memorable and  
even groupable node namings or can we do all of that through other  
attributes and environments and roles?  
\*) any other details that I don't even know that I don't know yet?

Thanks!

On Sun, Oct 21, 2012 at 1:49 PM, AJ Christensen [aj@junglist.gen.nz](mailto:aj@junglist.gen.nz) wrote:

> The machines already come with extremely useful names (ec2). Node name  
> currently can be explicitly set or reflects the machine host name, instance  
> ID. No?
> 
> I believe the instance ID system currently in use may have been developed by  
> some sort of computer scientist. Hard to say though.
> 
> The negativity, and I'll thank you for asking, stems from the repeated  
> requests over time for pretty snowflake node names of varying forms. The  
> answer remains the same, so obviously one might become a little jaded.
> 
> This doesn't need to be functionality baked into 'knife-ec2'. Not only that,  
> but naming / host name management, machine DNS (etc) are solved problems  
> during convergence time.
> 
> I hope this clarifies my original statement and I'd like to apologize for  
> the negativity, it doesn't really help.
> 
> I got 99 problems bit naming isn't one.
> 
> Cheers,
> 
> AJ
> 
> On Oct 21, 2012 10:28 AM, "James Light" [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com) wrote:
> 
> > Labels are for people who like naming things... like the whole field  
> > of computer scientists. All we do when it comes down to it is name  
> > things and refer to them by names that make sense to us to do things  
> > that are usually useful for some reason or another.
> > 
> > Why the negativity towards someone else's perception of how to name  
> > things usefully?
> > 
> > On Sun, Oct 21, 2012 at 12:53 PM, John Dewey [john@dewey.ws](mailto:john@dewey.ws) wrote:
> > 
> > > +1
> > > 
> > > On Sunday, October 21, 2012 at 9:51 AM, AJ Christensen wrote:
> > > 
> > > Labels are for jam jars, not machinery
> > > 
> > > --AJ
> > > 
> > > On Oct 21, 2012 11:21 PM, "Sachin Sagar Rai" [millisami@gmail.com](mailto:millisami@gmail.com)  
> > > wrote:
> > > 
> > > Ohai Chefs!
> > > 
> > > Last week, there was a good discussion on whether to bring the  
> > > --elastic-ip  
> > > attachment into the knife-ec2 and I hope that it will settle down and  
> > > get  
> > > release on the upcoming version.
> > > 
> > > But at this very same time, I'ld like to know and bring up the  
> > > discussion on  
> > > this pull req as well: [[KNIFE\_EC2-74] added new node-name-prefix option by nybble73 · Pull Request #61 · chef/knife-ec2 · GitHub](https://github.com/opscode/knife-ec2/pull/61)
> > > 
> > > I'm really positive about this option as well.
> > > 
> > > Want to hear about the community on this!
> > > 
> > > * * *
> > > 
> > > @millisami  
> > > ~ Sachin Sagar Rai  
> > > Ruby on Rails Developer  
> > > [http://tfm.com.np](http://tfm.com.np)  
> > > [http://nepalonrails.tumblr.com](http://nepalonrails.tumblr.com)  
> > > Sent with Sparrow

---

<div class="post-metadata">

**Author:** ![AJ\_Christensen](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/aj_christensen/32/525_2.png) [@AJ\_Christensen](https://discourse.chef.io/u/AJ_Christensen)\
**Post date:** [October 21, 2012, 6:37pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/7 "2012-10-21T18:37:28Z")

</div>

Reponses inline:

On Oct 21, 2012 11:27 AM, "James Light" [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com) wrote:

> Okay. I may misunderstand the topic here. It sounds like you're saying  
> that the i-xXxXxxwhatever-whatever-whocan-remember-any-of-this AWS EC2  
> instance ID string should be good enough for everyone to use as a node  
> name? Either that or they should settle for naming their nodes  
> explicitly at creation time.

That is exactly my point.

> And I thought what the pull request in the link was asking for was a  
> way to have a prefix set so that one could launch a whole formation of  
> nodes and have the node names all be able to be easily matched later  
> by a trivial regular expression.

That is fair, and may be useful for bulk regex operations.

> If your point is that this functionality is not needed specifically in  
> the EC2 plugin, I think you have a strong stance and can be shown to  
> be correct.

Indeed.

> If your point is that this functionality isn't needed for any reason  
> at all anywhere, I think you are being inflexible and at least  
> bordering on what seems myopic.
> 
> You don't really need this in the ec2 plugin per-se as I don't see  
> this functionality being EC2-specific. Where I'm at, we already have a  
> script that we call that just interactively asks for the knife options  
> while suggesting the ones that we generally use to launch a base linux  
> instance with no frills (which is the usual case if we're launching  
> from knife), so it would be easy to add a 'Node Name Prefix' option  
> and then use that for repeated knife calls. No EC2 plugin patching  
> needed.
> 
> While I don't understand the orignal idea of why this needs to be an  
> EC2 plugin, but I also don't understand what I interpret as implying  
> that some md5-lookin hash thingmabobbyboo is a memorable name. Unique  
> and useful as a unique ID in the context of dynamic generation, YES,  
> but I'm a human being and sometime I'd also like to remember what the  
> heck I just called one of my programmable resources so I can easily  
> refer to it later.
> 
> What am I missing on both sides of this please?

You are saying you are a human and want to remember machine designations,  
probably storing these in your head and a document (isn't that pretty?). At  
what point does this stop being scalable? I consider that myopic.

I am am engineer. I don't remember node names. When I need to locate one, I  
have a full text index database of the node data available to me. I can  
perform batch operations on a much more accurate scale thanks to the power  
of Node Data.

> \*) how is this ec2 specific?

Definitely is not; this came up before we even had knife ec2

> \*) are there any situations where it is useful to have memorable and  
> even groupable node namings or can we do all of that through other  
> attributes and environments and roles?

Potentially in infrastructures which do not have suitable systems for  
machine identification / resolution.

Cheers,

AJ

> \*) any other details that I don't even know that I don't know yet?
> 
> Thanks!
> 
> On Sun, Oct 21, 2012 at 1:49 PM, AJ Christensen [aj@junglist.gen.nz](mailto:aj@junglist.gen.nz)  
> wrote:
> 
> > The machines already come with extremely useful names (ec2). Node name  
> > currently can be explicitly set or reflects the machine host name,  
> > instance  
> > ID. No?
> > 
> > I believe the instance ID system currently in use may have been  
> > developed by  
> > some sort of computer scientist. Hard to say though.
> > 
> > The negativity, and I'll thank you for asking, stems from the repeated  
> > requests over time for pretty snowflake node names of varying forms. The  
> > answer remains the same, so obviously one might become a little jaded.
> > 
> > This doesn't need to be functionality baked into 'knife-ec2'. Not only  
> > that,  
> > but naming / host name management, machine DNS (etc) are solved problems  
> > during convergence time.
> > 
> > I hope this clarifies my original statement and I'd like to apologize  
> > for  
> > the negativity, it doesn't really help.
> > 
> > I got 99 problems bit naming isn't one.
> > 
> > Cheers,
> > 
> > AJ
> > 
> > On Oct 21, 2012 10:28 AM, "James Light" [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com)  
> > wrote:
> > 
> > > Labels are for people who like naming things... like the whole field  
> > > of computer scientists. All we do when it comes down to it is name  
> > > things and refer to them by names that make sense to us to do things  
> > > that are usually useful for some reason or another.
> > > 
> > > Why the negativity towards someone else's perception of how to name  
> > > things usefully?
> > > 
> > > On Sun, Oct 21, 2012 at 12:53 PM, John Dewey [john@dewey.ws](mailto:john@dewey.ws) wrote:
> > > 
> > > > +1
> > > > 
> > > > On Sunday, October 21, 2012 at 9:51 AM, AJ Christensen wrote:
> > > > 
> > > > Labels are for jam jars, not machinery
> > > > 
> > > > --AJ
> > > > 
> > > > On Oct 21, 2012 11:21 PM, "Sachin Sagar Rai" [millisami@gmail.com](mailto:millisami@gmail.com)  
> > > > wrote:
> > > > 
> > > > Ohai Chefs!
> > > > 
> > > > Last week, there was a good discussion on whether to bring the  
> > > > --elastic-ip  
> > > > attachment into the knife-ec2 and I hope that it will settle down and  
> > > > get  
> > > > release on the upcoming version.
> > > > 
> > > > But at this very same time, I'ld like to know and bring up the  
> > > > discussion on  
> > > > this pull req as well: [[KNIFE\_EC2-74] added new node-name-prefix option by nybble73 · Pull Request #61 · chef/knife-ec2 · GitHub](https://github.com/opscode/knife-ec2/pull/61)
> > > > 
> > > > I'm really positive about this option as well.
> > > > 
> > > > Want to hear about the community on this!
> > > > 
> > > > * * *
> > > > 
> > > > @millisami  
> > > > ~ Sachin Sagar Rai  
> > > > Ruby on Rails Developer  
> > > > [http://tfm.com.np](http://tfm.com.np)  
> > > > [http://nepalonrails.tumblr.com](http://nepalonrails.tumblr.com)  
> > > > Sent with Sparrow

---

<div class="post-metadata">

**Author:** ![J\_Light](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/j_light/32/412_2.png) [@J\_Light](https://discourse.chef.io/u/J_Light)\
**Post date:** [October 21, 2012, 7:06pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/8 "2012-10-21T19:06:13Z")

</div>

Cool. Mostly inline responses as well.

On Sun, Oct 21, 2012 at 2:37 PM, AJ Christensen [aj@junglist.gen.nz](mailto:aj@junglist.gen.nz) wrote:

> Reponses inline:
> 
> On Oct 21, 2012 11:27 AM, "James Light" [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com) wrote:
> 
> > Okay. I may misunderstand the topic here. It sounds like you're saying  
> > that the i-xXxXxxwhatever-whatever-whocan-remember-any-of-this AWS EC2  
> > instance ID string should be good enough for everyone to use as a node  
> > name? Either that or they should settle for naming their nodes  
> > explicitly at creation time.
> 
> That is exactly my point.

No problem with that.

> > And I thought what the pull request in the link was asking for was a  
> > way to have a prefix set so that one could launch a whole formation of  
> > nodes and have the node names all be able to be easily matched later  
> > by a trivial regular expression.
> 
> That is fair, and may be useful for bulk regex operations.

Well, yea, only thing is if I'm doing bulk operations on nodes  
regularly, I'm probably going to use knife exec scripts and then, once  
again, I don't need the info in the node name specifically and  
exclusively.

[----snip----]

> > but I'm a human being and sometime I'd also like to remember what the  
> > heck I just called one of my programmable resources so I can easily  
> > refer to it later.
> > 
> > What am I missing on both sides of this please?
> 
> You are saying you are a human and want to remember machine designations,  
> probably storing these in your head and a document (isn't that pretty?). At  
> what point does this stop being scalable? I consider that myopic.

Well, whether or not it is scalable or not doesn't mean that its  
myopic. I'm open to both points... which is actually the precise  
opposite of myopic. 😉

> I am am engineer. I don't remember node names. When I need to locate one, I  
> have a full text index database of the node data available to me. I can  
> perform batch operations on a much more accurate scale thanks to the power  
> of Node Data.

And you still need to name that node data in a way that is memorable  
to be able to do anything dynamic and spontaneous with it. You're just  
choosing to name other things memorable names instead of the entire  
node itself. This shows the approach of nodes are just resources that  
are used to accomplish something else and that seems to be very much  
in line with advanced chef usage. Kudos!

> > \*) how is this ec2 specific?
> 
> Definitely is not; this came up before we even had knife ec2
> 
> > \*) are there any situations where it is useful to have memorable and  
> > even groupable node namings or can we do all of that through other  
> > attributes and environments and roles?
> 
> Potentially in infrastructures which do not have suitable systems for  
> machine identification / resolution.

And _that_ seems to be the real crux of the issue here.

There need to be memorable names somewhere, be that in the entire  
domain of node data or some range of node data that may even be a  
subset of the original domain.

To say that we are using the full power of node data seems to me to  
necessitate that we posses the ability and willingness to use all of  
the node data in flexible ways.

The only difference seems to be that you remember the context and  
semantics of your node data and someone else wants to further abstract  
that so that this context and semantics is implicitly referred to by a  
specific node attribute, that of the node name.

I really fail to see why it is "bad" to treat a node name like a  
snowflake when it is useful and why it is "good" to treat a node name  
like a sacred and immutable thing that is only must be exactly  
something that is so special that it isn't special at all.  
Just seems silly.

It scales because I make it scale. That's my job. What I name things  
in the process of making things scale is flexible. When I am starting  
things out I have some names that make sense to me. When I dug a bit  
deeper it started to make more sense how to use node data in a logical  
way so that the names themselves don't need to be snowflakey anymore,  
BUT for someone else's needs they may still need the memorable names.  
I think that really scalability also applies to the concept of being  
able to do things quickly that have not been thought of before. A  
scalability of work flow so that when something unexpected comes up  
tomorrow (which it always does) that I can get it done quickly without  
being forced to do something in a way that is sideways towards my end  
goal.

I agree that having snowflakey node names in your head to keep track  
of everything stops working at some point. I disagree that it never  
works at all and I think it is important for each Chef to be able to  
Choose Their Workflow.

All this talk about snowflakes makes me want to go snowboarding.  
Opscode to Hood Mountain conference / outing someday??

Thx for taking the time to express your opinions with only a subtle  
tinge of jade. 😉

> Cheers,
> 
> AJ
> 
> > \*) any other details that I don't even know that I don't know yet?
> > 
> > Thanks!
> > 
> > On Sun, Oct 21, 2012 at 1:49 PM, AJ Christensen [aj@junglist.gen.nz](mailto:aj@junglist.gen.nz)  
> > wrote:
> > 
> > > The machines already come with extremely useful names (ec2). Node name  
> > > currently can be explicitly set or reflects the machine host name,  
> > > instance  
> > > ID. No?
> > > 
> > > I believe the instance ID system currently in use may have been  
> > > developed by  
> > > some sort of computer scientist. Hard to say though.
> > > 
> > > The negativity, and I'll thank you for asking, stems from the repeated  
> > > requests over time for pretty snowflake node names of varying forms. The  
> > > answer remains the same, so obviously one might become a little jaded.
> > > 
> > > This doesn't need to be functionality baked into 'knife-ec2'. Not only  
> > > that,  
> > > but naming / host name management, machine DNS (etc) are solved problems  
> > > during convergence time.
> > > 
> > > I hope this clarifies my original statement and I'd like to apologize  
> > > for  
> > > the negativity, it doesn't really help.
> > > 
> > > I got 99 problems bit naming isn't one.
> > > 
> > > Cheers,
> > > 
> > > AJ
> > > 
> > > On Oct 21, 2012 10:28 AM, "James Light" [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com)  
> > > wrote:
> > > 
> > > > Labels are for people who like naming things... like the whole field  
> > > > of computer scientists. All we do when it comes down to it is name  
> > > > things and refer to them by names that make sense to us to do things  
> > > > that are usually useful for some reason or another.
> > > > 
> > > > Why the negativity towards someone else's perception of how to name  
> > > > things usefully?
> > > > 
> > > > On Sun, Oct 21, 2012 at 12:53 PM, John Dewey [john@dewey.ws](mailto:john@dewey.ws) wrote:
> > > > 
> > > > > +1
> > > > > 
> > > > > On Sunday, October 21, 2012 at 9:51 AM, AJ Christensen wrote:
> > > > > 
> > > > > Labels are for jam jars, not machinery
> > > > > 
> > > > > --AJ
> > > > > 
> > > > > On Oct 21, 2012 11:21 PM, "Sachin Sagar Rai" [millisami@gmail.com](mailto:millisami@gmail.com)  
> > > > > wrote:
> > > > > 
> > > > > Ohai Chefs!
> > > > > 
> > > > > Last week, there was a good discussion on whether to bring the  
> > > > > --elastic-ip  
> > > > > attachment into the knife-ec2 and I hope that it will settle down and  
> > > > > get  
> > > > > release on the upcoming version.
> > > > > 
> > > > > But at this very same time, I'ld like to know and bring up the  
> > > > > discussion on  
> > > > > this pull req as well: [[KNIFE\_EC2-74] added new node-name-prefix option by nybble73 · Pull Request #61 · chef/knife-ec2 · GitHub](https://github.com/opscode/knife-ec2/pull/61)
> > > > > 
> > > > > I'm really positive about this option as well.
> > > > > 
> > > > > Want to hear about the community on this!
> > > > > 
> > > > > * * *
> > > > > 
> > > > > @millisami  
> > > > > ~ Sachin Sagar Rai  
> > > > > Ruby on Rails Developer  
> > > > > [http://tfm.com.np](http://tfm.com.np)  
> > > > > [http://nepalonrails.tumblr.com](http://nepalonrails.tumblr.com)  
> > > > > Sent with Sparrow

---

<div class="post-metadata">

**Author:** ![reset](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/reset/32/490_2.png) [@reset](https://discourse.chef.io/u/reset)\
**Post date:** [October 21, 2012, 10:05pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/9 "2012-10-21T22:05:04Z")

</div>

You could think of AJ's approach of identifying systems as something similar to Ruby's approach of a type system. We don't have one - instead we ask an object how it behaves with "respond\_to?".

AJ is asking you to think differently by dropping the need to name a node as something you'll keep in your head or a spreadsheet in favor of using node data to identify your machines.

You can ask a node if its your database master for production for a given application based on a set of attributes which make up its behavior (or role). You could even just simplify this by asking about a node's run\_list.

Much like we do not need a static type system in Ruby - You simply do not need to name your nodes if you look at it this way.

@resetexistence

On Oct 21, 2012, at 12:06 PM, James Light [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com) wrote:

> Cool. Mostly inline responses as well.
> 
> On Sun, Oct 21, 2012 at 2:37 PM, AJ Christensen [aj@junglist.gen.nz](mailto:aj@junglist.gen.nz) wrote:
> 
> > Reponses inline:
> > 
> > On Oct 21, 2012 11:27 AM, "James Light" [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com) wrote:
> > 
> > > Okay. I may misunderstand the topic here. It sounds like you're saying  
> > > that the i-xXxXxxwhatever-whatever-whocan-remember-any-of-this AWS EC2  
> > > instance ID string should be good enough for everyone to use as a node  
> > > name? Either that or they should settle for naming their nodes  
> > > explicitly at creation time.
> > 
> > That is exactly my point.
> 
> No problem with that.
> 
> > > And I thought what the pull request in the link was asking for was a  
> > > way to have a prefix set so that one could launch a whole formation of  
> > > nodes and have the node names all be able to be easily matched later  
> > > by a trivial regular expression.
> > 
> > That is fair, and may be useful for bulk regex operations.
> 
> Well, yea, only thing is if I'm doing bulk operations on nodes  
> regularly, I'm probably going to use knife exec scripts and then, once  
> again, I don't need the info in the node name specifically and  
> exclusively.
> 
> [----snip----]
> 
> > > but I'm a human being and sometime I'd also like to remember what the  
> > > heck I just called one of my programmable resources so I can easily  
> > > refer to it later.
> > > 
> > > What am I missing on both sides of this please?
> > 
> > You are saying you are a human and want to remember machine designations,  
> > probably storing these in your head and a document (isn't that pretty?). At  
> > what point does this stop being scalable? I consider that myopic.
> 
> Well, whether or not it is scalable or not doesn't mean that its  
> myopic. I'm open to both points... which is actually the precise  
> opposite of myopic. 😉
> 
> > I am am engineer. I don't remember node names. When I need to locate one, I  
> > have a full text index database of the node data available to me. I can  
> > perform batch operations on a much more accurate scale thanks to the power  
> > of Node Data.
> 
> And you still need to name that node data in a way that is memorable  
> to be able to do anything dynamic and spontaneous with it. You're just  
> choosing to name other things memorable names instead of the entire  
> node itself. This shows the approach of nodes are just resources that  
> are used to accomplish something else and that seems to be very much  
> in line with advanced chef usage. Kudos!
> 
> > > \*) how is this ec2 specific?
> > 
> > Definitely is not; this came up before we even had knife ec2
> > 
> > > \*) are there any situations where it is useful to have memorable and  
> > > even groupable node namings or can we do all of that through other  
> > > attributes and environments and roles?
> > 
> > Potentially in infrastructures which do not have suitable systems for  
> > machine identification / resolution.
> 
> And _that_ seems to be the real crux of the issue here.
> 
> There need to be memorable names somewhere, be that in the entire  
> domain of node data or some range of node data that may even be a  
> subset of the original domain.
> 
> To say that we are using the full power of node data seems to me to  
> necessitate that we posses the ability and willingness to use all of  
> the node data in flexible ways.
> 
> The only difference seems to be that you remember the context and  
> semantics of your node data and someone else wants to further abstract  
> that so that this context and semantics is implicitly referred to by a  
> specific node attribute, that of the node name.
> 
> I really fail to see why it is "bad" to treat a node name like a  
> snowflake when it is useful and why it is "good" to treat a node name  
> like a sacred and immutable thing that is only must be exactly  
> something that is so special that it isn't special at all.  
> Just seems silly.
> 
> It scales because I make it scale. That's my job. What I name things  
> in the process of making things scale is flexible. When I am starting  
> things out I have some names that make sense to me. When I dug a bit  
> deeper it started to make more sense how to use node data in a logical  
> way so that the names themselves don't need to be snowflakey anymore,  
> BUT for someone else's needs they may still need the memorable names.  
> I think that really scalability also applies to the concept of being  
> able to do things quickly that have not been thought of before. A  
> scalability of work flow so that when something unexpected comes up  
> tomorrow (which it always does) that I can get it done quickly without  
> being forced to do something in a way that is sideways towards my end  
> goal.
> 
> I agree that having snowflakey node names in your head to keep track  
> of everything stops working at some point. I disagree that it never  
> works at all and I think it is important for each Chef to be able to  
> Choose Their Workflow.
> 
> All this talk about snowflakes makes me want to go snowboarding.  
> Opscode to Hood Mountain conference / outing someday??
> 
> Thx for taking the time to express your opinions with only a subtle  
> tinge of jade. 😉
> 
> > Cheers,
> > 
> > AJ
> > 
> > > \*) any other details that I don't even know that I don't know yet?
> > > 
> > > Thanks!
> > > 
> > > On Sun, Oct 21, 2012 at 1:49 PM, AJ Christensen [aj@junglist.gen.nz](mailto:aj@junglist.gen.nz)  
> > > wrote:
> > > 
> > > > The machines already come with extremely useful names (ec2). Node name  
> > > > currently can be explicitly set or reflects the machine host name,  
> > > > instance  
> > > > ID. No?
> > > > 
> > > > I believe the instance ID system currently in use may have been  
> > > > developed by  
> > > > some sort of computer scientist. Hard to say though.
> > > > 
> > > > The negativity, and I'll thank you for asking, stems from the repeated  
> > > > requests over time for pretty snowflake node names of varying forms. The  
> > > > answer remains the same, so obviously one might become a little jaded.
> > > > 
> > > > This doesn't need to be functionality baked into 'knife-ec2'. Not only  
> > > > that,  
> > > > but naming / host name management, machine DNS (etc) are solved problems  
> > > > during convergence time.
> > > > 
> > > > I hope this clarifies my original statement and I'd like to apologize  
> > > > for  
> > > > the negativity, it doesn't really help.
> > > > 
> > > > I got 99 problems bit naming isn't one.
> > > > 
> > > > Cheers,
> > > > 
> > > > AJ
> > > > 
> > > > On Oct 21, 2012 10:28 AM, "James Light" [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com)  
> > > > wrote:
> > > > 
> > > > > Labels are for people who like naming things... like the whole field  
> > > > > of computer scientists. All we do when it comes down to it is name  
> > > > > things and refer to them by names that make sense to us to do things  
> > > > > that are usually useful for some reason or another.
> > > > > 
> > > > > Why the negativity towards someone else's perception of how to name  
> > > > > things usefully?
> > > > > 
> > > > > On Sun, Oct 21, 2012 at 12:53 PM, John Dewey [john@dewey.ws](mailto:john@dewey.ws) wrote:
> > > > > 
> > > > > > +1
> > > > > > 
> > > > > > On Sunday, October 21, 2012 at 9:51 AM, AJ Christensen wrote:
> > > > > > 
> > > > > > Labels are for jam jars, not machinery
> > > > > > 
> > > > > > --AJ
> > > > > > 
> > > > > > On Oct 21, 2012 11:21 PM, "Sachin Sagar Rai" [millisami@gmail.com](mailto:millisami@gmail.com)  
> > > > > > wrote:
> > > > > > 
> > > > > > Ohai Chefs!
> > > > > > 
> > > > > > Last week, there was a good discussion on whether to bring the  
> > > > > > --elastic-ip  
> > > > > > attachment into the knife-ec2 and I hope that it will settle down and  
> > > > > > get  
> > > > > > release on the upcoming version.
> > > > > > 
> > > > > > But at this very same time, I'ld like to know and bring up the  
> > > > > > discussion on  
> > > > > > this pull req as well: [[KNIFE\_EC2-74] added new node-name-prefix option by nybble73 · Pull Request #61 · chef/knife-ec2 · GitHub](https://github.com/opscode/knife-ec2/pull/61)
> > > > > > 
> > > > > > I'm really positive about this option as well.
> > > > > > 
> > > > > > Want to hear about the community on this!
> > > > > > 
> > > > > > * * *
> > > > > > 
> > > > > > @millisami  
> > > > > > ~ Sachin Sagar Rai  
> > > > > > Ruby on Rails Developer  
> > > > > > [http://tfm.com.np](http://tfm.com.np)  
> > > > > > [http://nepalonrails.tumblr.com](http://nepalonrails.tumblr.com)  
> > > > > > Sent with Sparrow

---

<div class="post-metadata">

**Author:** ![Leo\_Dirac\_SR](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/leo_dirac_sr/32/618_2.png) [@Leo\_Dirac\_SR](https://discourse.chef.io/u/Leo_Dirac_SR)\
**Post date:** [October 21, 2012, 11:29pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/10 "2012-10-21T23:29:35Z")

</div>

Here's how I'd summarize the two sides of the issue:

Using manually-assigned names for nodes is not a best practice. It does  
not scale up well, and encourages other problems like inefficient use of  
hardware. It's better to use the searchable database to identify nodes.  
Not allowing names encourages users to adopt best practices more quickly.

On the flip side, having simple names for nodes is convenient and  
simplifying when used appropriately. It's probably fine for many small  
installations. It's also particularly helpful for people who are still  
learning to use chef. In either of these cases, a search query is likely  
to be more complex and harder to remember than a manually assigned name.

To me the question boils down to how we want to shape chef's learning  
curve. Not allowing names makes it steeper at the beginning -- harder to  
learn, but by forcing new users to understand and adopt practices that  
scale well, they'll have fewer problems as they grow.

IMHO technologies are almost always more successful when they make  
themselves easier to use by a broader set of people. I see it as better to  
have more users relying on and contributing to the technology even if some  
of them aren't using it perfectly than to turn people away who are  
considering it. So I'd side with allowing names, but with the appropriate  
warnings about how they might be leading to bad habits.

On Sun, Oct 21, 2012 at 3:05 PM, Jamie Winsor [jamie@vialstudios.com](mailto:jamie@vialstudios.com)wrote:

> You could think of AJ's approach of identifying systems as something  
> similar to Ruby's approach of a type system. We don't have one - instead we  
> ask an object how it behaves with "respond\_to?".
> 
> AJ is asking you to think differently by dropping the need to name a node  
> as something you'll keep in your head or a spreadsheet in favor of using  
> node data to identify your machines.
> 
> You can ask a node if its your database master for production for a given  
> application based on a set of attributes which make up its behavior (or  
> role). You could even just simplify this by asking about a node's run\_list.
> 
> Much like we do not need a static type system in Ruby - You simply do not  
> need to name your nodes if you look at it this way.
> 
> @resetexistence
> 
> On Oct 21, 2012, at 12:06 PM, James Light [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com)  
> wrote:
> 
> > Cool. Mostly inline responses as well.
> > 
> > On Sun, Oct 21, 2012 at 2:37 PM, AJ Christensen [aj@junglist.gen.nz](mailto:aj@junglist.gen.nz)  
> > wrote:
> > 
> > > Reponses inline:
> > > 
> > > On Oct 21, 2012 11:27 AM, "James Light" [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com)  
> > > wrote:
> > > 
> > > > Okay. I may misunderstand the topic here. It sounds like you're saying  
> > > > that the i-xXxXxxwhatever-whatever-whocan-remember-any-of-this AWS EC2  
> > > > instance ID string should be good enough for everyone to use as a node  
> > > > name? Either that or they should settle for naming their nodes  
> > > > explicitly at creation time.
> > > 
> > > That is exactly my point.
> > 
> > No problem with that.
> > 
> > > > And I thought what the pull request in the link was asking for was a  
> > > > way to have a prefix set so that one could launch a whole formation of  
> > > > nodes and have the node names all be able to be easily matched later  
> > > > by a trivial regular expression.
> > > 
> > > That is fair, and may be useful for bulk regex operations.
> > 
> > Well, yea, only thing is if I'm doing bulk operations on nodes  
> > regularly, I'm probably going to use knife exec scripts and then, once  
> > again, I don't need the info in the node name specifically and  
> > exclusively.
> > 
> > [----snip----]
> > 
> > > > but I'm a human being and sometime I'd also like to remember what the  
> > > > heck I just called one of my programmable resources so I can easily  
> > > > refer to it later.
> > > > 
> > > > What am I missing on both sides of this please?
> > > 
> > > You are saying you are a human and want to remember machine  
> > > designations,  
> > > probably storing these in your head and a document (isn't that  
> > > pretty?). At  
> > > what point does this stop being scalable? I consider that myopic.
> > 
> > Well, whether or not it is scalable or not doesn't mean that its  
> > myopic. I'm open to both points... which is actually the precise  
> > opposite of myopic. 😉
> > 
> > > I am am engineer. I don't remember node names. When I need to locate  
> > > one, I  
> > > have a full text index database of the node data available to me. I can  
> > > perform batch operations on a much more accurate scale thanks to the  
> > > power  
> > > of Node Data.
> > 
> > And you still need to name that node data in a way that is memorable  
> > to be able to do anything dynamic and spontaneous with it. You're just  
> > choosing to name other things memorable names instead of the entire  
> > node itself. This shows the approach of nodes are just resources that  
> > are used to accomplish something else and that seems to be very much  
> > in line with advanced chef usage. Kudos!
> > 
> > > > \*) how is this ec2 specific?
> > > 
> > > Definitely is not; this came up before we even had knife ec2
> > > 
> > > > \*) are there any situations where it is useful to have memorable and  
> > > > even groupable node namings or can we do all of that through other  
> > > > attributes and environments and roles?
> > > 
> > > Potentially in infrastructures which do not have suitable systems for  
> > > machine identification / resolution.
> > 
> > And _that_ seems to be the real crux of the issue here.
> > 
> > There need to be memorable names somewhere, be that in the entire  
> > domain of node data or some range of node data that may even be a  
> > subset of the original domain.
> > 
> > To say that we are using the full power of node data seems to me to  
> > necessitate that we posses the ability and willingness to use all of  
> > the node data in flexible ways.
> > 
> > The only difference seems to be that you remember the context and  
> > semantics of your node data and someone else wants to further abstract  
> > that so that this context and semantics is implicitly referred to by a  
> > specific node attribute, that of the node name.
> > 
> > I really fail to see why it is "bad" to treat a node name like a  
> > snowflake when it is useful and why it is "good" to treat a node name  
> > like a sacred and immutable thing that is only must be exactly  
> > something that is so special that it isn't special at all.  
> > Just seems silly.
> > 
> > It scales because I make it scale. That's my job. What I name things  
> > in the process of making things scale is flexible. When I am starting  
> > things out I have some names that make sense to me. When I dug a bit  
> > deeper it started to make more sense how to use node data in a logical  
> > way so that the names themselves don't need to be snowflakey anymore,  
> > BUT for someone else's needs they may still need the memorable names.  
> > I think that really scalability also applies to the concept of being  
> > able to do things quickly that have not been thought of before. A  
> > scalability of work flow so that when something unexpected comes up  
> > tomorrow (which it always does) that I can get it done quickly without  
> > being forced to do something in a way that is sideways towards my end  
> > goal.
> > 
> > I agree that having snowflakey node names in your head to keep track  
> > of everything stops working at some point. I disagree that it never  
> > works at all and I think it is important for each Chef to be able to  
> > Choose Their Workflow.
> > 
> > All this talk about snowflakes makes me want to go snowboarding.  
> > Opscode to Hood Mountain conference / outing someday??
> > 
> > Thx for taking the time to express your opinions with only a subtle  
> > tinge of jade. 😉
> > 
> > > Cheers,
> > > 
> > > AJ
> > > 
> > > > \*) any other details that I don't even know that I don't know yet?
> > > > 
> > > > Thanks!
> > > > 
> > > > On Sun, Oct 21, 2012 at 1:49 PM, AJ Christensen [aj@junglist.gen.nz](mailto:aj@junglist.gen.nz)  
> > > > wrote:
> > > > 
> > > > > The machines already come with extremely useful names (ec2). Node name  
> > > > > currently can be explicitly set or reflects the machine host name,  
> > > > > instance  
> > > > > ID. No?
> > > > > 
> > > > > I believe the instance ID system currently in use may have been  
> > > > > developed by  
> > > > > some sort of computer scientist. Hard to say though.
> > > > > 
> > > > > The negativity, and I'll thank you for asking, stems from the repeated  
> > > > > requests over time for pretty snowflake node names of varying forms.  
> > > > > The  
> > > > > answer remains the same, so obviously one might become a little jaded.
> > > > > 
> > > > > This doesn't need to be functionality baked into 'knife-ec2'. Not only  
> > > > > that,  
> > > > > but naming / host name management, machine DNS (etc) are solved  
> > > > > problems  
> > > > > during convergence time.
> > > > > 
> > > > > I hope this clarifies my original statement and I'd like to apologize  
> > > > > for  
> > > > > the negativity, it doesn't really help.
> > > > > 
> > > > > I got 99 problems bit naming isn't one.
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > AJ
> > > > > 
> > > > > On Oct 21, 2012 10:28 AM, "James Light" [j.gareth.light@gmail.com](mailto:j.gareth.light@gmail.com)  
> > > > > wrote:
> > > > > 
> > > > > > Labels are for people who like naming things... like the whole field  
> > > > > > of computer scientists. All we do when it comes down to it is name  
> > > > > > things and refer to them by names that make sense to us to do things  
> > > > > > that are usually useful for some reason or another.
> > > > > > 
> > > > > > Why the negativity towards someone else's perception of how to name  
> > > > > > things usefully?
> > > > > > 
> > > > > > On Sun, Oct 21, 2012 at 12:53 PM, John Dewey [john@dewey.ws](mailto:john@dewey.ws) wrote:
> > > > > > 
> > > > > > > +1
> > > > > > > 
> > > > > > > On Sunday, October 21, 2012 at 9:51 AM, AJ Christensen wrote:
> > > > > > > 
> > > > > > > Labels are for jam jars, not machinery
> > > > > > > 
> > > > > > > --AJ
> > > > > > > 
> > > > > > > On Oct 21, 2012 11:21 PM, "Sachin Sagar Rai" [millisami@gmail.com](mailto:millisami@gmail.com)  
> > > > > > > wrote:
> > > > > > > 
> > > > > > > Ohai Chefs!
> > > > > > > 
> > > > > > > Last week, there was a good discussion on whether to bring the  
> > > > > > > --elastic-ip  
> > > > > > > attachment into the knife-ec2 and I hope that it will settle down  
> > > > > > > and  
> > > > > > > get  
> > > > > > > release on the upcoming version.
> > > > > > > 
> > > > > > > But at this very same time, I'ld like to know and bring up the  
> > > > > > > discussion on  
> > > > > > > this pull req as well: [[KNIFE\_EC2-74] added new node-name-prefix option by nybble73 · Pull Request #61 · chef/knife-ec2 · GitHub](https://github.com/opscode/knife-ec2/pull/61)
> > > > > > > 
> > > > > > > I'm really positive about this option as well.
> > > > > > > 
> > > > > > > Want to hear about the community on this!
> > > > > > > 
> > > > > > > * * *
> > > > > > > 
> > > > > > > @millisami  
> > > > > > > ~ Sachin Sagar Rai  
> > > > > > > Ruby on Rails Developer  
> > > > > > > [http://tfm.com.np](http://tfm.com.np)  
> > > > > > > [http://nepalonrails.tumblr.com](http://nepalonrails.tumblr.com)  
> > > > > > > Sent with Sparrow

---

<div class="post-metadata">

**Author:** ![Sascha\_Bates](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sascha_bates/32/504_2.png) [@Sascha\_Bates](https://discourse.chef.io/u/Sascha_Bates)\
**Post date:** [October 22, 2012, 12:35am UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/11 "2012-10-22T00:35:41Z")

</div>

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.

```
  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).

  So I'm following this discussion and wondering how people are
  actually visiting their servers and how much time they waste
  looking up IPs for ssh? We have a much smaller AWS installation
  and I do actually ec2-describe-instances|grep sometag and then
  ec2-describe-instances &lt;instanceid&gt; to get the IP address
  every time I want to go out there, which isn't often or I'd figure
  out a way to make it less painful.

  How do people cope with connecting to nodes when they all have
  nonsense names that potentially change often?

```

Sascha Bates  
| [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) | 612 850 0444 | sascha.bates@skype |  
sascha\_bates@yahoo |  
On 10/21/12 6:29 PM, Leo Dirac (SR) wrote:

> Here's how I'd summarize the two sides of the issue:
> 
> Using manually-assigned names for nodes is not a best  
> practice. It does not scale up well, and encourages other  
> problems like inefficient use of hardware. It's better to use  
> the searchable database to identify nodes. Not allowing names  
> encourages users to adopt best practices more quickly.
> 
> On the flip side, having simple names for nodes is convenient  
> and simplifying when used appropriately. It's probably fine for  
> many small installations. It's also particularly helpful for  
> people who are still learning to use chef. In either of these  
> cases, a search query is likely to be more complex and harder to  
> remember than a manually assigned name.
> 
> To me the question boils down to how we want to shape chef's  
> learning curve. Not allowing names makes it steeper at the  
> beginning -- harder to learn, but by forcing new users to  
> understand and adopt practices that scale well, they'll have  
> fewer problems as they grow.
> 
> IMHO technologies are almost always more successful when they  
> make themselves easier to use by a broader set of people. I see  
> it as better to have more users relying on and contributing to  
> the technology even if some of them aren't using it perfectly  
> than to turn people away who are considering it. So I'd side  
> with allowing names, but with the appropriate warnings about how  
> they might be leading to bad habits.
> 
> On Sun, Oct 21, 2012 at 3:05 PM, Jamie Winsor \<[jamie@vialstudios.com](mailto:jamie@vialstudios.com)\>  
> wrote:
> 
> > You could  
> > think of AJ's approach of identifying systems as something  
> > similar to Ruby's approach of a type system. We don't have  
> > one - instead we ask an object how it behaves with  
> > "respond\_to?".
> > 
> > ```
> > AJ is asking you to think differently by dropping the need
> > to name a node as something you'll keep in your head or a
> > spreadsheet in favor of using node data to identify your
> > machines.
> > 
> > You can ask a node if its your database master for
> > production for a given application based on a set of
> > attributes which make up its behavior (or role). You could
> > even just simplify this by asking about a node's run_list.
> > 
> > Much like we do not need a static type system in Ruby - You
> > simply do not need to name your nodes if you look at it this
> > way.
> > 
> > @resetexistence
> > 
> > On Oct 21, 2012, at 12:06 PM, James Light &lt;<a moz-do-not-send="true" href="mailto:j.gareth.light@gmail.com">j.gareth.light@gmail.com</a>&gt;
> > wrote:
> > 
> > &gt; Cool. Mostly inline responses as well.
> > 
> > &gt;
> > 
> > &gt; On Sun, Oct 21, 2012 at 2:37 PM, AJ Christensen
> > &lt;<a moz-do-not-send="true" href="mailto:aj@junglist.gen.nz">aj@junglist.gen.nz</a>&gt;
> > wrote:
> > 
> > &gt;&gt; Reponses inline:
> > 
> > &gt;&gt;
> > 
> > &gt;&gt; On Oct 21, 2012 11:27 AM, "James Light" &lt;<a moz-do-not-send="true" href="mailto:j.gareth.light@gmail.com">j.gareth.light@gmail.com</a>&gt;
> > wrote:
> > 
> > &gt;&gt;&gt;
> > 
> > &gt;&gt;&gt; Okay. I may misunderstand the topic here.
> > It sounds like you're saying
> > 
> > &gt;&gt;&gt; that the
> > i-xXxXxxwhatever-whatever-whocan-remember-any-of-this
> > AWS EC2
> > 
> > &gt;&gt;&gt; instance ID string should be good enough
> > for everyone to use as a node
> > 
> > &gt;&gt;&gt; name? Either that or they should settle for
> > naming their nodes
> > 
> > &gt;&gt;&gt; explicitly at creation time.
> > 
> > &gt;&gt;
> > 
> > &gt;&gt; That is exactly my point.
> > 
> > &gt;
> > 
> > &gt; No problem with that.
> > 
> > &gt;
> > 
> > &gt;
> > 
> > &gt;&gt;&gt;
> > 
> > &gt;&gt;&gt; And I thought what the pull request in the
> > link was asking for was a
> > 
> > &gt;&gt;&gt; way to have a prefix set so that one could
> > launch a whole formation of
> > 
> > &gt;&gt;&gt; nodes and have the node names all be able
> > to be easily matched later
> > 
> > &gt;&gt;&gt; by a trivial regular expression.
> > 
> > &gt;&gt;
> > 
> > &gt;&gt; That is fair, and may be useful for bulk regex
> > operations.
> > 
> > &gt;
> > 
> > &gt; Well, yea, only thing is if I'm doing bulk
> > operations on nodes
> > 
> > &gt; regularly, I'm probably going to use knife exec
> > scripts and then, once
> > 
> > &gt; again, I don't need the info in the node name
> > specifically and
> > 
> > &gt; exclusively.
> > 
> > &gt;
> > 
> > &gt; [----snip----]
> > 
> > &gt;&gt;&gt; but I'm a human being and sometime I'd also
> > like to remember what the
> > 
> > &gt;&gt;&gt; heck I just called one of my programmable
> > resources so I can easily
> > 
> > &gt;&gt;&gt; refer to it later.
> > 
> > &gt;&gt;&gt;
> > 
> > &gt;&gt;&gt; What am I missing on both sides of this
> > please?
> > 
> > &gt;&gt;
> > 
> > &gt;&gt; You are saying you are a human and want to
> > remember machine designations,
> > 
> > &gt;&gt; probably storing these in your head and a
> > document (isn't that pretty?). At
> > 
> > &gt;&gt; what point does this stop being scalable? I
> > consider that myopic.
> > 
> > &gt;
> > 
> > &gt; Well, whether or not it is scalable or not doesn't
> > mean that its
> > 
> > &gt; myopic. I'm open to both points... which is
> > actually the precise
> > 
> > &gt; opposite of myopic. ;)
> > 
> > &gt;
> > 
> > &gt;&gt;
> > 
> > &gt;&gt; I am am engineer. I don't remember node names.
> > When I need to locate one, I
> > 
> > &gt;&gt; have a full text index database of the node
> > data available to me. I can
> > 
> > &gt;&gt; perform batch operations on a much more
> > accurate scale thanks to the power
> > 
> > &gt;&gt; of Node Data.
> > 
> > &gt;
> > 
> > &gt; And you still need to name that node data in a way
> > that is memorable
> > 
> > &gt; to be able to do anything dynamic and spontaneous
> > with it. You're just
> > 
> > &gt; choosing to name other things memorable names
> > instead of the entire
> > 
> > &gt; node itself. This shows the approach of nodes are
> > just resources that
> > 
> > &gt; are used to accomplish something else and that
> > seems to be very much
> > 
> > &gt; in line with advanced chef usage. Kudos!
> > 
> > &gt;
> > 
> > &gt;&gt;
> > 
> > &gt;&gt;&gt;
> > 
> > &gt;&gt;&gt; *) how is this ec2 specific?
> > 
> > &gt;&gt;
> > 
> > &gt;&gt; Definitely is not; this came up before we even
> > had knife ec2
> > 
> > &gt;&gt;
> > 
> > &gt;&gt;&gt; *) are there any situations where it is
> > useful to have memorable and
> > 
> > &gt;&gt;&gt; even groupable node namings or can we do
> > all of that through other
> > 
> > &gt;&gt;&gt; attributes and environments and roles?
> > 
> > &gt;&gt;
> > 
> > &gt;&gt; Potentially in infrastructures which do not
> > have suitable systems for
> > 
> > &gt;&gt; machine identification / resolution.
> > 
> > &gt;
> > 
> > &gt; And *that* seems to be the real crux of the issue
> > here.
> > 
> > &gt;
> > 
> > &gt; There need to be memorable names somewhere, be that
> > in the entire
> > 
> > &gt; domain of node data or some range of node data that
> > may even be a
> > 
> > &gt; subset of the original domain.
> > 
> > &gt;
> > 
> > &gt; To say that we are using the full power of node
> > data seems to me to
> > 
> > &gt; necessitate that we posses the ability and
> > willingness to use all of
> > 
> > &gt; the node data in flexible ways.
> > 
> > &gt;
> > 
> > &gt; The only difference seems to be that you remember
> > the context and
> > 
> > &gt; semantics of your node data and someone else wants
> > to further abstract
> > 
> > &gt; that so that this context and semantics is
> > implicitly referred to by a
> > 
> > &gt; specific node attribute, that of the node name.
> > 
> > &gt;
> > 
> > &gt; I really fail to see why it is "bad" to treat a
> > node name like a
> > 
> > &gt; snowflake when it is useful and why it is "good" to
> > treat a node name
> > 
> > &gt; like a sacred and immutable thing that is only must
> > be exactly
> > 
> > &gt; something that is so special that it isn't special
> > at all.
> > 
> > &gt; Just seems silly.
> > 
> > &gt;
> > 
> > &gt; It scales because I make it scale. That's my job.
> > What I name things
> > 
> > &gt; in the process of making things scale is flexible.
> > When I am starting
> > 
> > &gt; things out I have some names that make sense to me.
> > When I dug a bit
> > 
> > &gt; deeper it started to make more sense how to use
> > node data in a logical
> > 
> > &gt; way so that the names themselves don't need to be
> > snowflakey anymore,
> > 
> > &gt; BUT for someone else's needs they may still need
> > the memorable names.
> > 
> > &gt; I think that really scalability also applies to the
> > concept of being
> > 
> > &gt; able to do things quickly that have not been
> > thought of before. A
> > 
> > &gt; scalability of work flow so that when something
> > unexpected comes up
> > 
> > &gt; tomorrow (which it always does) that I can get it
> > done quickly without
> > 
> > &gt; being forced to do something in a way that is
> > sideways towards my end
> > 
> > &gt; goal.
> > 
> > &gt;
> > 
> > &gt; I agree that having snowflakey node names in your
> > head to keep track
> > 
> > &gt; of everything stops working at some point. I
> > disagree that it never
> > 
> > &gt; works at all and I think it is important for each
> > Chef to be able to
> > 
> > &gt; Choose Their Workflow.
> > 
> > &gt;
> > 
> > &gt; All this talk about snowflakes makes me want to go
> > snowboarding.
> > 
> > &gt; Opscode to Hood Mountain conference / outing
> > someday??
> > 
> > &gt;
> > 
> > &gt; Thx for taking the time to express your opinions
> > with only a subtle
> > 
> > &gt; tinge of jade. ;)
> > 
> > &gt;
> > 
> > &gt;
> > 
> > &gt;&gt;
> > 
> > &gt;&gt; Cheers,
> > 
> > &gt;&gt;
> > 
> > &gt;&gt; AJ
> > 
> > &gt;&gt;
> > 
> > &gt;&gt;&gt; *) any other details that I don't even know
> > that I don't know yet?
> > 
> > &gt;&gt;&gt;
> > 
> > &gt;&gt;&gt; Thanks!
> > 
> > &gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;
> > 
> > &gt;&gt;&gt; On Sun, Oct 21, 2012 at 1:49 PM, AJ
> > Christensen &lt;<a moz-do-not-send="true" href="mailto:aj@junglist.gen.nz">aj@junglist.gen.nz</a>&gt;
> > 
> > &gt;&gt;&gt; wrote:
> > 
> > &gt;&gt;&gt;&gt; The machines already come with
> > extremely useful names (ec2). Node name
> > 
> > &gt;&gt;&gt;&gt; currently can be explicitly set or
> > reflects the machine host name,
> > 
> > &gt;&gt;&gt;&gt; instance
> > 
> > &gt;&gt;&gt;&gt; ID. No?
> > 
> > &gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt; I believe the instance ID system
> > currently in use may have been
> > 
> > &gt;&gt;&gt;&gt; developed by
> > 
> > &gt;&gt;&gt;&gt; some sort of computer scientist. Hard
> > to say though.
> > 
> > &gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt; The negativity, and I'll thank you for
> > asking, stems from the repeated
> > 
> > &gt;&gt;&gt;&gt; requests over time for pretty snowflake
> > node names of varying forms. The
> > 
> > &gt;&gt;&gt;&gt; answer remains the same, so obviously
> > one might become a little jaded.
> > 
> > &gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt; This doesn't need to be functionality
> > baked into 'knife-ec2'. Not only
> > 
> > &gt;&gt;&gt;&gt; that,
> > 
> > &gt;&gt;&gt;&gt; but naming / host name management,
> > machine DNS (etc) are solved problems
> > 
> > &gt;&gt;&gt;&gt; during convergence time.
> > 
> > &gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt; I hope this clarifies my original
> > statement and I'd like to apologize
> > 
> > &gt;&gt;&gt;&gt; for
> > 
> > &gt;&gt;&gt;&gt; the negativity, it doesn't really help.
> > 
> > &gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt; I got 99 problems bit naming isn't one.
> > 
> > &gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt; Cheers,
> > 
> > &gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt; AJ
> > 
> > &gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt; On Oct 21, 2012 10:28 AM, "James Light"
> > &lt;<a moz-do-not-send="true" href="mailto:j.gareth.light@gmail.com">j.gareth.light@gmail.com</a>&gt;
> > 
> > &gt;&gt;&gt;&gt; wrote:
> > 
> > &gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt; Labels are for people who like
> > naming things... like the whole field
> > 
> > &gt;&gt;&gt;&gt;&gt; of computer scientists. All we do
> > when it comes down to it is name
> > 
> > &gt;&gt;&gt;&gt;&gt; things and refer to them by names
> > that make sense to us to do things
> > 
> > &gt;&gt;&gt;&gt;&gt; that are usually useful for some
> > reason or another.
> > 
> > &gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt; Why the negativity towards someone
> > else's perception of how to name
> > 
> > &gt;&gt;&gt;&gt;&gt; things usefully?
> > 
> > &gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt; On Sun, Oct 21, 2012 at 12:53 PM,
> > John Dewey &lt;<a moz-do-not-send="true" href="mailto:john@dewey.ws">john@dewey.ws</a>&gt;
> > wrote:
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; +1
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; On Sunday, October 21, 2012 at
> > 9:51 AM, AJ Christensen wrote:
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; Labels are for jam jars, not
> > machinery
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; --AJ
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; On Oct 21, 2012 11:21 PM,
> > "Sachin Sagar Rai" &lt;<a moz-do-not-send="true" href="mailto:millisami@gmail.com">millisami@gmail.com</a>&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; wrote:
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; Ohai Chefs!
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; Last week, there was a good
> > discussion on whether to bring the
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; --elastic-ip
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; attachment into the knife-ec2
> > and I hope that it will settle down and
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; get
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; release on the upcoming
> > version.
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; But at this very same time,
> > I'ld like to know and bring up the
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; discussion on
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; this pull req as well: <a moz-do-not-send="true" href="https://github.com/opscode/knife-ec2/pull/61" target="_blank">https://github.com/opscode/knife-ec2/pull/61</a>
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; I'm really positive about this
> > option as well.
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; Want to hear about the
> > community on this!
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > -------------------------------------------
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; @millisami
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; ~ Sachin Sagar Rai
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; Ruby on Rails Developer
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; <a moz-do-not-send="true" href="http://tfm.com.np" target="_blank">http://tfm.com.np</a>
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; <a moz-do-not-send="true" href="http://nepalonrails.tumblr.com" target="_blank">http://nepalonrails.tumblr.com</a>
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt; Sent with Sparrow
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > &gt;&gt;&gt;&gt;&gt;&gt;
> > 
> > ```

---

<div class="post-metadata">

**Author:** ![BradKnowles](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bradknowles/32/99_2.png) [@BradKnowles](https://discourse.chef.io/u/BradKnowles)\
**Post date:** [October 22, 2012, 12:57am UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/12 "2012-10-22T00:57:56Z")

</div>

On Oct 21, 2012, at 5:35 PM, Sascha Bates [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) 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 [brad@shub-internet.org](mailto:brad@shub-internet.org)  
LinkedIn Profile: [http://tinyurl.com/y8kpxu](http://tinyurl.com/y8kpxu)

---

<div class="post-metadata">

**Author:** ![John\_Dewey](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/john_dewey/32/457_2.png) [@John\_Dewey](https://discourse.chef.io/u/John_Dewey)\
**Post date:** [October 22, 2012, 1:25am UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/13 "2012-10-22T01:25:30Z")

</div>

… and if you had to ssh around you would `knife ssh`. You care about the QUERY (roles,environment), not necessarily the individual server names.

On Sunday, October 21, 2012 at 5:57 PM, Brad Knowles wrote:

> On Oct 21, 2012, at 5:35 PM, Sascha Bates \<[sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) ([mailto:sascha.bates@gmail.com](mailto:sascha.bates@gmail.com))\> 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 \<[brad@shub-internet.org](mailto:brad@shub-internet.org) ([mailto:brad@shub-internet.org](mailto:brad@shub-internet.org))\>  
> LinkedIn Profile: [http://tinyurl.com/y8kpxu](http://tinyurl.com/y8kpxu)

---

<div class="post-metadata">

**Author:** ![Sascha\_Bates](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sascha_bates/32/504_2.png) [@Sascha\_Bates](https://discourse.chef.io/u/Sascha_Bates)\
**Post date:** [October 22, 2012, 2:56am UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/14 "2012-10-22T02:56:08Z")

</div>

```
_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

```
    | <a class="moz-txt-link-abbreviated" href="mailto:sascha.bates@gmail.com">sascha.bates@gmail.com</a> | 612 850 0444 | sascha.bates@skype |
    sascha_bates@yahoo | 
  On 10/21/12 7:57 PM, Brad Knowles wrote:

```

> ```
> On Oct 21, 2012, at 5:35 PM, Sascha Bates[\<sascha.bates@gmail.com\>](mailto:sascha.bates@gmail.com)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 [\<brad@shub-internet.org\>](mailto:brad@shub-internet.org)  
> LinkedIn Profile: [\<http://tinyurl.com/y8kpxu\>](http://tinyurl.com/y8kpxu)
> ```

---

<div class="post-metadata">

**Author:** ![AJ\_Christensen](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/aj_christensen/32/525_2.png) [@AJ\_Christensen](https://discourse.chef.io/u/AJ_Christensen)\
**Post date:** [October 22, 2012, 6:45am UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/15 "2012-10-22T06:45:19Z")

</div>

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" [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) 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 | [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) | 612 850 0444 | sascha.bates@skype| sascha\_bates@yahoo|  
> On 10/21/12 7:57 PM, Brad Knowles wrote:
> 
> On Oct 21, 2012, at 5:35 PM, Sascha Bates [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) 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 [brad@shub-internet.org](mailto:brad@shub-internet.org) [brad@shub-internet.org](mailto:brad@shub-internet.org)  
> LinkedIn Profile: [http://tinyurl.com/y8kpxu](http://tinyurl.com/y8kpxu) [http://tinyurl.com/y8kpxu](http://tinyurl.com/y8kpxu)

---

<div class="post-metadata">

**Author:** ![BradKnowles](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/bradknowles/32/99_2.png) [@BradKnowles](https://discourse.chef.io/u/BradKnowles)\
**Post date:** [October 22, 2012, 7:48am UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/16 "2012-10-22T07:48:18Z")

</div>

On Oct 21, 2012, at 7:56 PM, Sascha Bates [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) wrote:

> 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.

Just because you don't live in a perfect world is no reason to avoid working towards making your world more perfect.

Each time you have to manually ssh out to a given node to find or fix some problem, you should be asking yourself what you can do to help make this information available through other -- more automated -- means. The next time you have to do that same sort of thing, you should be asking yourself that same question again. By the third or fourth time, you should probably be working towards having something in place to do that instead so that there is unlikely to be a fifth or sixth time, at least for that particular type of problem.

You don't want to go around manually doing all the same sorts of things every time, because that doesn't leave you any room to be able to scale your infrastructure, or react to successfully handle serious problems. That probably also would not be conducive to your mental or physical health, either.

You don't have to have everything automated, everywhere, from Day One. But you should at least work towards the goal of having the right things automated in the right way -- and for the right reasons.

> Or possibly I'm the only person who doesn't work in a perfect world. Everyone else, back to your regularly scheduled Ironman Matrix.

Speaking only for myself, it's unlikely to be like Iron Man. It's more likely to be like Edison -- 99% perspiration and 1% inspiration, and learning many thousands of different ways to _not_ make a lightbulb. But there will hopefully be a few interesting/useful inventions and discoveries along the way.

I just hope we can have better working conditions, and avoid getting into nasty politics and lawsuits, etc... over who invented what and whose version of which thing is really the better thing.

--  
Brad Knowles [brad@shub-internet.org](mailto:brad@shub-internet.org)  
LinkedIn Profile: [http://tinyurl.com/y8kpxu](http://tinyurl.com/y8kpxu)

---

<div class="post-metadata">

**Author:** ![Sascha\_Bates](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sascha_bates/32/504_2.png) [@Sascha\_Bates](https://discourse.chef.io/u/Sascha_Bates)\
**Post date:** [October 22, 2012, 12:19pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/17 "2012-10-22T12:19:01Z")

</div>

You are absolutely right. I'm not going to argue with any of that  
sentiment. A lot of the stuff we do hurts me and some of the stuff i see  
our dev teams do makes me want to cry. I've been with this client 2  
months now and I have a long list of things I'd like to improve or turn  
around.

But when you're building a house where the barn used to be, sometimes  
you have to shovel some shit before you can lay down the hardwood floors  
or install the Viking appliances. We currently travel around a lot by  
the command line and that's not going to change in the next month or  
three. The easier I make that, the more brain cycles I free up for  
important work.

We're a team of 8 serving hundreds of people; our backlog of cards  
stretches into infinity. I think we have 3 agile dev teams and about 15  
more that are like, "wtf are all these tools and why do I have to know  
chef to write Java?" Friday I spent 4 hours walking two devs through  
setting up their private chef orgs and syncing 4 separate cookbook  
repos. Saturday I spent the morning writing a Jenkins job that automates  
the sync. Today I'll likely try to reconcile the openstack VM build we  
have to work with Private Chef and pray that I get a means of writing  
automated org creation soon as well.

It's strangely fun and satisfying bring the devops and automation gospel  
to the enterprise. But it's def not the same as building beautiful  
things from scratch.

#lifeintheenterprise

Sascha Bates | [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) | 612 850 0444 |  
sascha.bates@skype | sascha\_bates@yahoo |  
On 10/22/12 2:48 AM, Brad Knowles wrote:

> On Oct 21, 2012, at 7:56 PM, Sascha Bates [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) wrote:
> 
> > 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.  
> > Just because you don't live in a perfect world is no reason to avoid working towards making your world more perfect.
> 
> Each time you have to manually ssh out to a given node to find or fix some problem, you should be asking yourself what you can do to help make this information available through other -- more automated -- means. The next time you have to do that same sort of thing, you should be asking yourself that same question again. By the third or fourth time, you should probably be working towards having something in place to do that instead so that there is unlikely to be a fifth or sixth time, at least for that particular type of problem.
> 
> You don't want to go around manually doing all the same sorts of things every time, because that doesn't leave you any room to be able to scale your infrastructure, or react to successfully handle serious problems. That probably also would not be conducive to your mental or physical health, either.
> 
> You don't have to have everything automated, everywhere, from Day One. But you should at least work towards the goal of having the right things automated in the right way -- and for the right reasons.
> 
> > Or possibly I'm the only person who doesn't work in a perfect world. Everyone else, back to your regularly scheduled Ironman Matrix.  
> > Speaking only for myself, it's unlikely to be like Iron Man. It's more likely to be like Edison -- 99% perspiration and 1% inspiration, and learning many thousands of different ways to _not_ make a lightbulb. But there will hopefully be a few interesting/useful inventions and discoveries along the way.
> 
> I just hope we can have better working conditions, and avoid getting into nasty politics and lawsuits, etc... over who invented what and whose version of which thing is really the better thing.
> 
> --  
> Brad Knowles [brad@shub-internet.org](mailto:brad@shub-internet.org)  
> LinkedIn Profile: [http://tinyurl.com/y8kpxu](http://tinyurl.com/y8kpxu)

---

<div class="post-metadata">

**Author:** ![Tensibai](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tensibai/32/29_2.png) [@Tensibai](https://discourse.chef.io/u/Tensibai)\
**Post date:** [October 22, 2012, 12:38pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/18 "2012-10-22T12:38:50Z")

</div>

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" [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com)  
> 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 | [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) |  
> > 612 850 0444 | sascha.bates@skype | sascha\_bates@yahoo | On 10/21/12  
> > 7:57 PM, Brad Knowles wrote:
> > 
> > > On Oct 21, 2012, at 5:35 PM,  
> > > Sascha Bates [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) 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 [brad@shub-internet.org](mailto:brad@shub-internet.org)  
> > > LinkedIn Profile:  
> > > [http://tinyurl.com/y8kpxu](http://tinyurl.com/y8kpxu) [1]

## Links:

[1]  
[http://tinyurl.com/y8kpxu](http://tinyurl.com/y8kpxu)

---

<div class="post-metadata">

**Author:** ![Christopher\_Brown](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/christopher_brown/32/559_2.png) [@Christopher\_Brown](https://discourse.chef.io/u/Christopher_Brown)\
**Post date:** [October 22, 2012, 2:16pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/19 "2012-10-22T14:16:01Z")

</div>

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 \<[tensibai@iabis.net](mailto:tensibai@iabis.net)[mailto:tensibai@iabis.net](mailto:tensibai@iabis.net)\>  
Reply-To: "chef@lists.opscode.com[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)" \<[chef@lists.opscode.com](mailto:chef@lists.opscode.com)[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)\>  
Date: Monday, October 22, 2012 5:38 AM  
To: "chef@lists.opscode.com[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)" \<[chef@lists.opscode.com](mailto:chef@lists.opscode.com)[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)\>  
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” \<[sascha.bates@gmail.com](mailto:sascha.bates@gmail.com)[mailto:sascha.bates@gmail.com](mailto:sascha.bates@gmail.com)\> 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 | [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com)[mailto:sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) | 612 850 0444 | sascha.bates@skype | sascha\_bates@yahoo |  
On 10/21/12 7:57 PM, Brad Knowles wrote:

On Oct 21, 2012, at 5:35 PM, Sascha Bates [sascha.bates@gmail.com](mailto:sascha.bates@gmail.com)[mailto:sascha.bates@gmail.com](mailto:sascha.bates@gmail.com) 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 [brad@shub-internet.org](mailto:brad@shub-internet.org)[mailto:brad@shub-internet.org](mailto:brad@shub-internet.org)  
LinkedIn Profile: [http://tinyurl.com/y8kpxu](http://tinyurl.com/y8kpxu)[http://tinyurl.com/y8kpxu](http://tinyurl.com/y8kpxu)

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [October 22, 2012, 4:21pm UTC](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213/20 "2012-10-22T16:21:01Z")

</div>

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

[Next page](https://discourse.chef.io/t/bring-up-the-discussion-for-knife-ec2-node-name-prefix-option/3213.md?page=2)