Re: [ansible-project] Re: 'common' role updates my app RPM and prevents a handler to execute later on

2014-03-06 Thread Azul
ooOOo that's quite handy On 6 March 2014 20:09, James Cammarata wrote: > Are your in-house app RPMs in a custom yum repo? Because you could very > easily exclude that and do your system upgrade by using the yum module > rather than shell: > > yum: state=latest name=* disablerepo=cus

Re: [ansible-project] Re: 'common' role updates my app RPM and prevents a handler to execute later on

2014-03-06 Thread James Cammarata
Are your in-house app RPMs in a custom yum repo? Because you could very easily exclude that and do your system upgrade by using the yum module rather than shell: yum: state=latest name=* disablerepo=custom_repo_here On Thu, Mar 6, 2014 at 12:16 PM, Azul Inho wrote: > yes, that's what I am look

[ansible-project] Re: 'common' role updates my app RPM and prevents a handler to execute later on

2014-03-06 Thread Azul Inho
yes, that's what I am looking into now. I deploy the configuration for the app through a different task, which doesn't change very often. caking the RPM-initscripts to restart the app looks like the cleanest way forward. On Thursday, March 6, 2014 9:47:52 AM UTC, Johan Wärlander wrote: > > I'd

[ansible-project] Re: 'common' role updates my app RPM and prevents a handler to execute later on

2014-03-06 Thread Johan Wärlander
I'd normally have the RPM do the work of restarting after installation (upgrade), at least if it's always to be done, and is a safe thing. Given your role above, that seems to be true.. If so, you would only need the "common" role. Now, if you need to reconfigure stuff after installing the appl