looks_like_ec2? fallback gist

Hi,
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):

HTH


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

On Tue, Feb 21, 2012 at 12:05 AM, Hedge Hog hedgehogshiatus@gmail.com 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):

Robust ec2 meta-data collection · GitHub

I've been poking around that code as I've been discussing OHAI-310
[1]. How is it broken? What happens? Is there a bug for the issue
you're experiencing?

Bryan

[1] http://tickets.opscode.com/browse/OHAI-310

On Wed, Feb 22, 2012 at 2:58 AM, Bryan McLellan btm@loftninjas.org wrote:

On Tue, Feb 21, 2012 at 12:05 AM, Hedge Hog hedgehogshiatus@gmail.com 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):

Robust ec2 meta-data collection · GitHub

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.

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 thing0, ironic that there is an example of
this in the bug you cite.

For the moment I find it suffices to google for people publishing
gists/workarounds - just like this :slight_smile:

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

Yo,

On 22 February 2012 09:32, Hedge Hog hedgehogshiatus@gmail.com wrote:

On Wed, Feb 22, 2012 at 2:58 AM, Bryan McLellan btm@loftninjas.org wrote:

On Tue, Feb 21, 2012 at 12:05 AM, Hedge Hog hedgehogshiatus@gmail.com 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):

Robust ec2 meta-data collection · GitHub

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
NON-VPC instance; as that would NOT be CHEF-310 but ANOTHER ec2
plugin bug.

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

Patches to the problematic code in the official code base when tracked
per standard contribution policy is the best way to solve this -- 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 :slight_smile:

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

On Tue, Feb 21, 2012 at 3:32 PM, Hedge Hog hedgehogshiatus@gmail.com wrote:

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 thing0, ironic that there is an example of
this in the bug you cite.

For the moment I find it suffices to google for people publishing
gists/workarounds - just like this :slight_smile:

Yeah, that sucks sometimes, sorry dude. The tickets in the Opscode
support system can be a great help because they contain good
information to reproduce the problem, but sometimes the user makes
them private to protect sensitive data in there, then only the user
and Opscode can see the ticket. Maybe I could add a filter to hide
those comments on JIRA from non-opscode employees.

But still, there is no shortage of other people participating directly
on that ticket. I consider JIRA to be the central authority on all
Chef bugs (which is why even Opscode support tickets get linked back
there). It's really nice when you're working with the code and you can
review the history and discussion of the problem in one place, which
is admittedly different from just looking for a workaround on the
interweb.

Bryan

I guess this shows Opscodes perspective vs. some random dude in the
community quite well; props for replying at the same time.

--AJ

On 22 February 2012 09:44, Bryan McLellan btm@loftninjas.org wrote:

On Tue, Feb 21, 2012 at 3:32 PM, Hedge Hog hedgehogshiatus@gmail.com wrote:

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 thing0, ironic that there is an example of
this in the bug you cite.

For the moment I find it suffices to google for people publishing
gists/workarounds - just like this :slight_smile:

Yeah, that sucks sometimes, sorry dude. The tickets in the Opscode
support system can be a great help because they contain good
information to reproduce the problem, but sometimes the user makes
them private to protect sensitive data in there, then only the user
and Opscode can see the ticket. Maybe I could add a filter to hide
those comments on JIRA from non-opscode employees.

But still, there is no shortage of other people participating directly
on that ticket. I consider JIRA to be the central authority on all
Chef bugs (which is why even Opscode support tickets get linked back
there). It's really nice when you're working with the code and you can
review the history and discussion of the problem in one place, which
is admittedly different from just looking for a workaround on the
interweb.

Bryan

On Wed, Feb 22, 2012 at 7:44 AM, AJ Christensen aj@junglist.gen.nz wrote:

Yo,

On 22 February 2012 09:32, Hedge Hog hedgehogshiatus@gmail.com wrote:

On Wed, Feb 22, 2012 at 2:58 AM, Bryan McLellan btm@loftninjas.org wrote:

On Tue, Feb 21, 2012 at 12:05 AM, Hedge Hog hedgehogshiatus@gmail.com 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):

Robust ec2 meta-data collection · GitHub

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.

NON-VPC instance; as that would NOT be CHEF-310 but ANOTHER ec2
plugin bug.

Yes this is a non-vpc setting.

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 thing0, 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 :slight_smile:

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

Yo,

Seems you misunderstood a comment, the 'some random dude' was
referring to me, anyway, comments in-line, flame-bait engaged:

On 22 February 2012 10:58, Hedge Hog hedgehogshiatus@gmail.com wrote:

On Wed, Feb 22, 2012 at 7:44 AM, AJ Christensen aj@junglist.gen.nz wrote:

Yo,

On 22 February 2012 09:32, Hedge Hog hedgehogshiatus@gmail.com wrote:

On Wed, Feb 22, 2012 at 2:58 AM, Bryan McLellan btm@loftninjas.org wrote:

On Tue, Feb 21, 2012 at 12:05 AM, Hedge Hog hedgehogshiatus@gmail.com 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):

Robust ec2 meta-data collection · GitHub

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)

You can search for keywords on the opscode tickets database with the
built in, Google Chrome compatible search engine; it was automatically
added to my browser, query like: 'tickets.ops '

You can search for keywords on the opscode tickets database with
Google itself, with a query like: "keyword site:tickets.opscode.com"

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
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? Why do you think that is acceptable?

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 thing0, 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 :slight_smile:

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

On Wed, Feb 22, 2012 at 9:11 AM, AJ Christensen aj@junglist.gen.nz 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 hedgehogshiatus@gmail.com wrote:

On Wed, Feb 22, 2012 at 7:44 AM, AJ Christensen aj@junglist.gen.nz wrote:

Yo,

On 22 February 2012 09:32, Hedge Hog hedgehogshiatus@gmail.com wrote:

On Wed, Feb 22, 2012 at 2:58 AM, Bryan McLellan btm@loftninjas.org wrote:

On Tue, Feb 21, 2012 at 12:05 AM, Hedge Hog hedgehogshiatus@gmail.com 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):

Robust ec2 meta-data collection · GitHub

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 '

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 thing0, 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 :slight_smile:

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