[chef] Re: Re: Re: Re: Re: Re: looks_like_ec2? fallback gist

[Hedge Hog < >]

On Wed, Feb 22, 2012 at 9:11 AM, AJ Christensen 
<
 >
 wrote:
> Yo,
>
> Seems you misunderstood a comment, the 'some random dude' was
> referring to *me*, anyway, comments in-line, flame-bait engaged:
>

Apologies.

> On 22 February 2012 10:58, Hedge Hog 
> <
 >
>  wrote:
>> On Wed, Feb 22, 2012 at 7:44 AM, AJ Christensen 
>> <
 >
>>  wrote:
>>> Yo,
>>>
>>> On 22 February 2012 09:32, Hedge Hog 
>>> <
 >
>>>  wrote:
>>>> On Wed, Feb 22, 2012 at 2:58 AM, Bryan McLellan 
>>>> <
 >
>>>>  wrote:
>>>>> On Tue, Feb 21, 2012 at 12:05 AM, Hedge Hog 
>>>>> <
 >
>>>>>  wrote:
>>>>>> Ohai `looks_like_ec2?` seems to be on the blink in version 0.6.10 on a
>>>>>> tiny ec2 instance (if the detail helps/matters it was launched via a
>>>>>> stack template).
>>>>>>
>>>>>> Below is the gist I've been resorting to that has proved robust in
>>>>>> these situations (0.6.4 was another occasion):
>>>>>>
>>>>>> https://gist.github.com/1873800
>>>>>
>>>>> I've been poking around that code as I've been discussing OHAI-310
>>>>> [1]. How is it broken?
>>>>
>>>> looks_like_ec2? returns false/nil when it should return true.
>>>
>>> I've been working on this bug a bit recently, it's specifically
>>> related to instances launched in VPC -- VPC subnets do not have the
>>> standard AWS ARP table entries.
>>>
>>> As always, when helping with Chef diagnostics, it's great to supply
>>> DEBUG level logs and/or the output of related commands, in this case,
>>> I'd love to see the ohai debug output, and the arp table, from the
>>> machine where looks_like_ec2 is failing.. *especially* if it is a
>>
>> I would love to have given it, but the project github readme, the wiki
>> gave no hints.
>> Google gave no hints in this use case (non-command line).  So rather
>> than whine about things I can't change (my employer won't consent to
>> what Opscode asks for before they will allow me to make contributions)
>> I posted a gist indicating a workaround - I know, a terrible attitude.
>
> Are you referring to the ohai project github readme? The DEVELOPMENT
> and LINKS section both contain references to the Opscode-managed
> community components, e.g. wiki (how to contribute) and issues
> (tickets.opscode.com)

Yep and both those pages would have required further digging - further
digging that Google told me *they* had been unsuccessful at... so I
moved on to create the workaround gist.

>
> You can search for keywords on the opscode tickets database with the
> built in,

I pretty much assumed google had done that, and some opscode tickets
did show up in Google's list - but describing commandline debugging
feature request, which is not my use case.

>Google Chrome compatible search engine; it was automatically
> added to my browser, query like: 'tickets.ops <TAB> <QUERY>'
>
> You can search for keywords on the opscode tickets database with
> Google itself, with a query like: "keyword site:tickets.opscode.com"

I always keep searches general, there is more gold out there, than in
any single mine.

>
>>
>>> NON-VPC instance; as that would *NOT* be CHEF-310 but ANOTHER ec2
>>> plugin bug.
>>
>> Yes this is a non-vpc setting.
>
> Cool, mind opening another bug? You have not met the conditions of
> OHAI-310, which is VPC specific.
>
> Alternately, Can you supply the diagnostics I asked for, so that if

Seriously, I've engaged in this to show good will but show me where
there is a how to debug Ohai page.

> you are unwilling to open a ticket, I might try to reproduce and log
> one myself?
>
> Why does your employer insist on preventing you from engaging with the
> community in the standard way?

They certainly don't.  But to them 'in the standard way' means any
open source license that does not require them to sign anything.  They
seem to trust my judgement.
Again, a serious question: How more accommodating do you want them to be?

>Why do you think that is acceptable?

Okay I get, it you are joking. Right?
But in case you are serious: How about they employ me and allow me to
work on opensource projects as I see fit to get my job done.
Good enough reason?

Best wishes
>
> Cheers,
>
> AJ
>
>>
>>>
>>>>
>>>> Given the moving target(s) your trying to hit I wonder if it isn't
>>>> better to just say that people have to target a cloud VM by setting
>>>> some attribute - it is not clear what that convention should be.
>>>>
>>>> looks_like_ec? whould then become looks_cloudy?, check for that
>>>> attribute(s) and compose what information it can for that provider?
>>>>
>>>> This would be quite a change in behavior, but maybe could be
>>>> implemented so that the attribute only need be set once, anywhere?
>>>>
>>>>> What happens?
>>>>
>>>> As above.  It don't see any exception.
>>>>
>>>>> Is there a bug for the issue
>>>>> you're experiencing?
>>>>
>>>> Possibly, apologies for this but I don't really hunt in opscode's bug
>>>> database too much anymore - from memory I do have an account (for a
>>>> different role) I could use.  Simple reason is that, if you are
>>>> serious about participating in squashing a bug, it is too frustrating
>>>> to encounter this sort of thing[0], ironic that there is an example of
>>>> this in the bug you cite.
>>>
>>> What's the problem here? Link is dead, I assume it doesn't provide
>>> anything useful to the bug.
>>
>> And I assume it does, or more accurately I generally assume that no
>> reporter is just whiling away idle hours submitting details to bug
>> reports.
>>
>>> We know the cause of the problem and the
>>> problematic code, all that remains is to design and develop a fix. The
>>> bug has a valid, thorough description.
>>
>> Seriously, who said it didn't?  It sounds like you are trying to be 
>> offended.
>> You're confusing my stated reason for not digging through Opscode bug
>> database results list as first port of call.  Instead I dig though the
>> Google result list, and if that has opscode tickets in it great.
>>
>>>
>>> Patches to the problematic code in the official code base when tracked
>>> per standard contribution policy is the best way to solve this
>>
>> Not everyone is in circumstances where they can satisfy that policy.
>> They haven't commit a crime/sin/immorality.
>> Open you mind more positively, just because someone doesn't do what
>> you'd like them to do, does not excuse casting aspersions on their
>> motives or character.
>>
>> Best wishes
>>
>> 'some random dude'
>>
>>> -- not
>>> gists floating around on a mailing list.
>>>
>>> Cheers,
>>>
>>> --AJ
>>>
>>>>
>>>> For the moment I find it suffices to google for people publishing
>>>> gists/workarounds - just like this :)
>>>>
>>>> [0]: 
>>>> http://tickets.opscode.com/browse/OHAI-310?focusedCommentId=21505&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-21505
>>>>
>>>>>
>>>>> Bryan
>>>>>
>>>>> [1] http://tickets.opscode.com/browse/OHAI-310
>>>>
>>>>
>>>>
>>>> --
>>>> πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
>>>> [The fox knows many things, but the hedgehog knows one big thing.]
>>>>   Archilochus, Greek poet (c. 680 BC – c. 645 BC)
>>>> http://hedgehogshiatus.com
>>
>>
>>
>> --
>> πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
>> [The fox knows many things, but the hedgehog knows one big thing.]
>>   Archilochus, Greek poet (c. 680 BC – c. 645 BC)
>> http://hedgehogshiatus.com



-- 
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
  Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://hedgehogshiatus.com