According to the forman hooks docs, I should be able to hook into the
after_destroy event for the pulp_task_status:
[root@slik01 ~]# foreman-rake hooks:events[katello/pulp_task_status]
/usr/share/foreman/lib/foreman.rb:8: warning: already initialized constant
Foreman::UUID_REGEXP
/usr/share/foreman/lib/foreman.rb:8: warning: previous definition of
UUID_REGEXP was here
after_commit
after_create
after_destroy
after_find
after_initialize
after_rollback
after_save
after_touch
after_update
after_validate
after_validation
before_create
before_destroy
before_save
before_update
before_validate
before_validation
I would think this event *should* be triggered once the task sync task is
complete, but when I run a sync, the event never fires. I know that my hook
script works and is registering to the correct event from the debug output.
My hook script works if I copy it to a different event. It seems this event
doesn't work for pulp_sync_status either.
What is the expected behavior for these events? When should they fire? How
can I run a hook script when a sync task completes?
It’s been a week. Nothing on this? Would I be better off asking on the Development list?
@katello, any thoughts on this one?
I think i figured it out. It looks like the hooks are triggered off of Active Record callbacks, but looking at the source code, I don’t see any Active Record events being triggered. This kind of makes sense - Active Record is for database updates, but Pulp is mostly a separate system (that I assume we interact with via Pulp’s REST API) so it won’t really trigger any Active Record events here. If I’m reading this right, we can only call a hook script if the task goes into an error state.
I was hoping to avoid it, but it looks like I am going to have to code out a distributor plugin for pulp so that I can start promoting content to the lifecycle environment with my salt forumla once the repo sync finishes.
1 Like
Yeah, that makes sense, I hadn’t spotted that this was Pulp-side stuff. I guess @bmbouter will be excited to hear about new plugins 
Sorry for missing this earlier. You are correct there is no way to do this currently. I thought it might be easy (and was a good excuse to play with foreman-hooks, so i added support for it here: https://github.com/Katello/katello/pull/7141
I did notice that foreman_hooks seems to make some assumptions that aren’t true in katello and does not properly pass the json representation to stdin. It looks like this is an issue with all katello models. However, even with this it appears the hook is still called. I’ve opened a PR against foreman_hooks to hopefully correct this: https://github.com/theforeman/foreman_hooks/pull/52
This should be easier than creating your own custom distributor plugin in pulp !
Thanks! That is awesome and will definitely save me some headache! I should be able to monkey-patch it after install with my salt formula until/if it is accepted upstream and makes it into an actual release.
Justin, Did you run into this issue setting up the hooks by any chance?
Yep, it should be fixed in https://github.com/theforeman/foreman_hooks/pull/52 (in conjunction with the katello PR).
This doesn’t fix it for all katello models but does for repository.
I thought that might be the case. I’ll mark that in the bug. When I apply https://github.com/Katello/katello/pull/7141 however, it breaks /usr/sbin/foreman-rake db:migrate. It seems I can only apply it after install. (You can rake it manually after-the-fact to see the issue though)
It looks like applying https://github.com/theforeman/foreman_hooks/pull/52 after install makes it so that the foreman-tasks service cannot be restarted - for 1.16 at least. I suspect it can’t find Actions::EntryAction
NVMD. Figured it out. Copied over the wrong file.
1 Like
