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

[Alex Kiernan < >]

On Sun, Jun 9, 2013 at 5:51 PM, Mike 
<
 >
 wrote:
>> 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.

How it is today - all of the proposed solutions remove the need for
special cased interpreter use on EL5.

Basically, I was agreeing with you :)

Just waiting on the test-suite run to complete before pushing new
branches which include minitest assertions.

> -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



-- 
Alex Kiernan