[chef-dev] Re: [chef] Re: notifies :before

[Xabier de Zuazo < >]

[Thread moved to chef-dev]

 Hello Daniel,

On Fri, 22 Nov 2013 12:07:49 -0800
Daniel DeLeo 
<
 >
 wrote:

[...] 
> >  
> > I'm the one who tried to implement this a year ago. I proposed a
> > solution for the :before in this comment:
> >  
> > https://tickets.opscode.com/browse/CHEF-2421?focusedCommentId=29465&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-29465
> >  
> > This solution included why-run support. In fact, it was easier for
> > me to implement this with why-run than without it.
> >  
> > After this solution was proposed, I know you talked a lot about it
> > and whether to add this feature to Chef or not. Even you asked on
> > this list. Much time was spent on this.
> >  
> > Time passed and the issue was finally closed putting it to "Won't
> > fix" state. But I didn't received any feedback about my code and I
> > didn't know how to improve it or what was the way forward.
> >  
[...]
> 
> What happened here is, when we first implemented why run mode, we
> thought that we could restructure the way that providers work to do
> the following:  
> 
> 1. Examine the system
> 2. Compile a list of actions (as ruby Proc objects) that would
> converge the system to the desired state 3. Execute each action
> generated in step 2.
> 
> This was right around the time you submitted your patch, so it seemed
> sensible that we could just do:
> 
> 1. Examine the system
> 2. Compile a list of actions (as ruby Proc objects) that would
> converge the system to the desired state
> 
> 2a. Run before notifications
> 
> 3. Execute each action generated in step 2.
> 
> At the same time that you were updating your patch, we learned that
> what we’d done by restructuring the providers to work that way was
> based on faulty assumptions and made the system more complicated and
> difficult to debug. In particular, whether or not a provider needs to
> take some action may depend on what the provider did in a previous
> step (this was most apparent for complicated providers like deploy).
> So we changed it to work more like it did previously:
> 
> 1. Examine some aspect of the system
> 2. Run some code that converges that aspect of the system to the
> desired state 3. Repeat 1-2 until all aspects of the system described
> by a resource are in the desired state.
> 
> Unfortunately, this meant that we fundamentally broke the things your
> patch needed to work, after we suggested you could take advantage of
> them. I personally feel quite terrible that this happened. Sorry.
> 
> I know this is a valuable feature for some people and implementing
> the same behavior on your own is a PITA, so I’ve been trying to dream
> up ways that it could work without a scary level of implementation
> complexity. [...]
> 

 Thanks for your detailed reply. Don't worry. I know it's a long ticket
 and this makes it really difficult to review :-)

 I reviewed my patches and, in short, the events of the ticket were:

1. My first PR.
2. You recommended me to use why-run to predict updated_by_last_action.
3. Updated to use why-run.
4. You told me that CHEF-3589 broke my path.
5. Rebased and logic changed to work with CHEF-3589.
6. Won't fix.

 Since then, it seems that you have not made ​​big changes to why-run
 logic. I mean, this code seems to work in current master. I rebased it
 here (fixing some small conflicts):

https://github.com/onddo/chef/compare/CHEF-2421-3

 I tested it with some simple recipes and seems to work.

 I know my proposal is far from being perfect. But I find it strange
 that it was rejected without giving me a chance to improve it. Maybe I
 was misguided, but AFAIK nobody wrote me about it :-S

 Anyway, based on this code, do you think it appropriate for me to open
 a new ticket and propose as a solution? (I can not open the previous
 ticket) Or you just don't like my solution and you are looking for
 something else?

 Cheers,

-- 
Xabier de Zuazo Oteiza
IT System Administrator - Onddo Labs S.L.
www.onddo.com
--------------------------------------------------------------------
Public Key = http://www.onddo.com/xabier_zuazo.pub
Key Fingerprint = 8EFA 5B17 7275 5F1F 42B2  26B4 8E18 8B67 9DE1 9468
--------------------------------------------------------------------

Attachment: signature.asc
Description: PGP signature