Workaround when FQDN not defined

[organicveggie]

Hi,

We've found a few circumstances in our 0.9.14 Chef environment out at EC2 where node[:fqdn] is not defined. We've never managed to get to the bottom of the problem, but it causes pychef to crash. These commits introduce a method for checking if an attribute exists and provide the ability to specify a function for the hostname_attr to provide a workaround for scenarios like using the EC2 internal host name when the fqdn attribute is not defined.

-Sean

[organicveggie]

Sorry about the blanket except, obviously my Python is more than a bit rusty. :)

[organicveggie]

Sorry about the blanket except, obviously my Python is more than a bit rusty. :)

[organicveggie]

Regarding the hostname attr changes... I can make the parameter a function. Or I can make the code support either a function or a string. Any preferences between the two approaches?

[organicveggie]

Regarding the hostname attr changes... I can make the parameter a function. Or I can make the code support either a function or a string. Any preferences between the two approaches?

[organicveggie]

One more follow up question. As a refresher, I've got a situation where at least one of my Chef clients does not have a "fqdn" attribute. I've spent a lot of time trying to track it down, but I've never caught the guilty party. Nor do I understand how it even happened. That said, if the "fqdn" attribute exists, I would prefer to use that. If the "fqdn" attribute doesn't exist, I'm willing to fall back on the EC2 hostname.

So, it wouldn't really help me to make the hostname_attr parameter a function unless that function took something like the row.object.attributes object as parameter. Does that make sense? Any suggestions for a better approach?

[organicveggie]

One more follow up question. As a refresher, I've got a situation where at least one of my Chef clients does not have a "fqdn" attribute. I've spent a lot of time trying to track it down, but I've never caught the guilty party. Nor do I understand how it even happened. That said, if the "fqdn" attribute exists, I would prefer to use that. If the "fqdn" attribute doesn't exist, I'm willing to fall back on the EC2 hostname.

So, it wouldn't really help me to make the hostname_attr parameter a function unless that function took something like the row.object.attributes object as parameter. Does that make sense? Any suggestions for a better approach?

[organicveggie]

Last comment, I swear. This could be done via a partial function:

def hostname_attr_by_string(attribute_name, node_attributes):
    return node_attributes.get_dotted(attribute_name)

class Roledef(object):
    def __init__(self, name, api, hostname_attr):
        self.hostname_attr = hasattr(hostname_attr, '__call__') ? hostname_attr : partial(hostname_attr_by_string, hostname_attr)

    def __call__(self):
        for row in Search('node', 'roles:'+self.name, api=self.api):
            yield self.hostname_attr(row.object.attributes)

Would something like that be acceptable?

[organicveggie]

Last comment, I swear. This could be done via a partial function:

def hostname_attr_by_string(attribute_name, node_attributes):
    return node_attributes.get_dotted(attribute_name)

class Roledef(object):
    def __init__(self, name, api, hostname_attr):
        self.hostname_attr = hasattr(hostname_attr, '__call__') ? hostname_attr : partial(hostname_attr_by_string, hostname_attr)

    def __call__(self):
        for row in Search('node', 'roles:'+self.name, api=self.api):
            yield self.hostname_attr(row.object.attributes)

Would something like that be acceptable?

[coderanger]

I wouldn't do it quite like that, more like:

attr = self.hostname_attr(node) if callable(self.hostname_attr) else self.hostname_attr

Could also be fixed with some subclass hooks, but thats a little harder to deal with code reuse given the factory function.

[coderanger]

I wouldn't do it quite like that, more like:

attr = self.hostname_attr(node) if callable(self.hostname_attr) else self.hostname_attr

Could also be fixed with some subclass hooks, but thats a little harder to deal with code reuse given the factory function.

[organicveggie]

Thanks, that's an excellent suggestion. I've taken that approach and included it in the pull request.

[organicveggie]

Thanks, that's an excellent suggestion. I've taken that approach and included it in the pull request.

[coderanger]

Syntax error here :-)

[coderanger]

Other than ^^ looks great!

[coderanger]

Other than ^^ looks great!

[organicveggie]

Bah! :)

Clearly I'm spending too much time in Java/Ruby land.

[organicveggie]

Bah! :)

Clearly I'm spending too much time in Java/Ruby land.

[coderanger]

Thanks for the patch!

[coderanger]

Thanks for the patch!

[coderanger]

Just as a warning for when you update to the latest version, I changed this behavior in a backwards-incompatible way. On the plus side, the defaults for chef_roledefs() now do exactly what your example is :-)

[coderanger]

Just as a warning for when you update to the latest version, I changed this behavior in a backwards-incompatible way. On the plus side, the defaults for chef_roledefs() now do exactly what your example is :-)