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


#1

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

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://nepalonrails.tumblr.com
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


#2

Labels are for jam jars, not machinery

–AJ
On Oct 21, 2012 11:21 PM, “Sachin Sagar Rai” 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: 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://nepalonrails.tumblr.com
Sent with Sparrow http://www.sparrowmailapp.com/?sig


#3

+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: 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://nepalonrails.tumblr.com
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


#4

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 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 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: 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://nepalonrails.tumblr.com
Sent with Sparrow


#5

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 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 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
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: 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://nepalonrails.tumblr.com
Sent with Sparrow


#6

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 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 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 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
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: 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://nepalonrails.tumblr.com
Sent with Sparrow


#7

Reponses inline:

On Oct 21, 2012 11:27 AM, “James Light” 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
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
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 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
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: 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://nepalonrails.tumblr.com
Sent with Sparrow


#8

Cool. Mostly inline responses as well.

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

Reponses inline:

On Oct 21, 2012 11:27 AM, “James Light” 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. :wink:

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

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
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
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 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
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: 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://nepalonrails.tumblr.com
Sent with Sparrow


#9

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 wrote:

Cool. Mostly inline responses as well.

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

Reponses inline:

On Oct 21, 2012 11:27 AM, “James Light” 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. :wink:

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

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
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
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 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
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: 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://nepalonrails.tumblr.com
Sent with Sparrow


#10

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

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
wrote:

Cool. Mostly inline responses as well.

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

Reponses inline:

On Oct 21, 2012 11:27 AM, “James Light” 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. :wink:

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

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
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
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 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
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: 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://nepalonrails.tumblr.com
Sent with Sparrow


#11

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

#12

On Oct 21, 2012, at 5:35 PM, Sascha Bates 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
LinkedIn Profile: http://tinyurl.com/y8kpxu


#13

… 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)> 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


#14
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> 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>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>


#15

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 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 | 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 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 brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu http://tinyurl.com/y8kpxu


#16

On Oct 21, 2012, at 7:56 PM, Sascha Bates 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
LinkedIn Profile: http://tinyurl.com/y8kpxu


#17

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 | 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 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
LinkedIn Profile: http://tinyurl.com/y8kpxu


#18

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
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 |
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 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
LinkedIn Profile:
http://tinyurl.com/y8kpxu [1]

Links:

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


#19

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.netmailto:tensibai@iabis.net>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Monday, October 22, 2012 5:38 AM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto: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.commailto: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.commailto: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.commailto: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.orgmailto:brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxuhttp://tinyurl.com/y8kpxu


#20

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