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

[Mike < >]

> the defaults. Consuming the python recipe on EL5 using all the
> defaults, then needing to know that you have to pull one of those
> levers in order to use the virtualenv LWRP seems wrong to me.

I don't think I understand which proposed solution this is referring to.
-M

On Sun, Jun 9, 2013 at 1:47 AM, Alex Kiernan 
<
 >
 wrote:
> At the time I was focussed on getting test kitchen working and just
> exercising the LWRP was sufficient to show the problem. Having gone
> back for another look at chef-client it's pretty clear how to add
> those assertions and would improve the tests, I'll go have another
> look.
>
> For me, the premise should be about giving some cross platform
> consistency; the levers are there if you need to go tweak, but you
> should only need to pull them if you've a genuine need to diverge from
> the defaults. Consuming the python recipe on EL5 using all the
> defaults, then needing to know that you have to pull one of those
> levers in order to use the virtualenv LWRP seems wrong to me.
>
> On Sat, Jun 8, 2013 at 9:44 PM, Mike 
> <
 >
>  wrote:
>> 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
>
>
>
> --
> Alex Kiernan