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

[Jamie Winsor < >]

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

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