[chef] Re: Re: Re: Re: Re: COOK-3084 - wrong python on RHEL5

[Mike < >]

Alex,

I looked through the code, looks cool that you've got TK running.
Beyond having test cookbooks that exercise the LWRP, I didn't see
actual tests that assert a given state.
Were they missing?

Steven - I somewhat disagree about the "distance" of an attribute
percolating into a provider - I think that if the cookbook provides
sane defaults for attributes used, and an operator chooses to override
that particular attribute, then it is somewhat incumbent upon the
operator to read the docs and understand the impact of the override.

In this particular case, we would "protect them from themselves" -
since we are already declaring a preferred interpreter binary for the
target platform, remaining consistent with the declaration makes sense
to me.

So my vote would be for the Patch version, since the current behavior is 
broken.

-M


On Thu, Jun 6, 2013 at 4:11 PM, Alex Kiernan 
<
 >
 wrote:
> Tests completed across all platforms on the avoid-venv-python branch
> successfully. Should I update the ticket back to fix provided and point at
> this branch?
>
> On 6 Jun 2013 19:20, "Alex Kiernan" 
> <
 >
>  wrote:
>>
>> Four branches pushed:
>>
>> - simple tests for this issue:
>> https://github.com/akiernan/python/tree/add-venv-tests
>> - patch level change: https://github.com/akiernan/python/tree/handle-rhel5
>> - minor level
>> change:https://github.com/akiernan/python/tree/avoid-venv-python
>> - major level change:
>> https://github.com/akiernan/python/tree/remove-interpreter
>>
>> All three changes pass for CentOS 5.9/6.4 package installs; I'm leaving
>> the minor level change (the proposed patch earlier in this thread) running
>> the full suite and will update the ticket assuming it passes.
>>
>>
>> On Thu, Jun 6, 2013 at 5:42 PM, Alex Kiernan 
>> <
 >
>> wrote:
>>>
>>> A big +1 from me for the -1 on the ticket... you've made me go and get
>>> test-kitchen working :)
>>>
>>> I've added a test-kitchen test cookbook to show the problem and I'm just
>>> testing out the three branches which do what I think are the options:
>>>
>>> - patch level, fix up what's passed to --python (my original patch)
>>> - minor level, don't pass in --python unless interpreter is explicitly
>>> specified
>>> - major level, drop interpreter altogether
>>>
>>>  May or may not get to it this evening, depends how soon my wife makes it
>>> home (I gather the traffic's terrible, so I may get it done :))
>>>
>>>
>>> On Thu, Jun 6, 2013 at 2:59 PM, Steven Danna 
>>> <
 >
>>>  wrote:
>>>>
>>>> On 6/6/13 6:49 AM, Mike wrote:
>>>>
>>>> > Q: Can you use node attributes in providers? When do they resolve, and
>>>> > if a subsequent attribute is set later in the run, how does that
>>>> > affect this?
>>>> >
>>>> > If the answer is "it's all good and cool - setting
>>>> > node['python']['binary'] in a role/env/override attribute later works
>>>> > as expected", then I think I'm on board with the change.
>>>>
>>>> For most cases it will work as expected.  I believe that certain methods
>>>> of updating attributes inside a recipe could cause problems, but I would
>>>> have have to do some experimentation to be sure.
>>>>
>>>> Overall, however, I don't like using node attributes to modify resource
>>>> behavior behind the scenes like this as it puts the data which modifies
>>>> the behavior of a resource pretty far from the resource itself.
>>>>
>>>> Cheers,
>>>>
>>>> Steven
>>>>
>>>>
>>>>
>>>> --
>>>> Steven Danna
>>>> Systems Engineer, Opscode, Inc
>>>> GPG Key: http://stevendanna.github.com/downloads/code/public.key
>>>>
>>>
>>>
>>>
>>> --
>>> Alex Kiernan
>>
>>
>>
>>
>> --
>> Alex Kiernan