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

[James Light < >]

Cool. Mostly inline responses as well.

On Sun, Oct 21, 2012 at 2:37 PM, AJ Christensen 
<
 >
 wrote:
> Reponses inline:
>
> On Oct 21, 2012 11:27 AM, "James Light" 
> <
 >
>  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 
>> <
 >
>> 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" 
>> > <
 >
>> > 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 
>> >> <
 >
>> >>  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" 
>> >> > <
 >
>> >> > 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
>> >> >
>> >> >