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


Chronological Thread 
  • From: Alex Kiernan < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: COOK-3084 - wrong python on RHEL5
  • Date: Sun, 9 Jun 2013 06:47:08 +0100

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



Archive powered by MHonArc 2.6.16.

§