Provide way to append/prepend plugins to processing_hooks w/o overriding the defaults

[Dmitry Tantsur]

<lucasagomes> I mean, if someone downstream have a custom processing_hooks I think they want to not change it when discoverd changes
<lucasagomes> that prevents discoverd downstream from running something they don't want to
<lucasagomes> or... lemme rephrase, not that they don't want to
<dtantsur> lucasagomes, not necessary, e.g. we only need to insert a couple of plugins
<dtantsur> actually the default set of plugins is something you very rarely want to change, if ever
<lucasagomes> but they don't want to run more or less hooks when they update discoverd if they have a custom processing_hooks, they might just want to run exactly the same
<lucasagomes> right
<dtantsur> lucasagomes, they can still use just 'processing_hooks' and override everything like before. But I'd like us (RH) to work with default discoverd + plugins
<lucasagomes> dtantsur, I find it complicated to have 2 lists of hooks that will run
<dtantsur> another option would be to have 'processing_hooks' that acts as append, and also some knd of blacklist
<lucasagomes> right, I don't know. I kinda like the whitelist more
<lucasagomes> as is right now
<lucasagomes> it feels safer if you want to have control over ur enviroment, so that new things won't run unless you explicity tell it to run
<lucasagomes> kinda liek enabled_drivers for ironic
<dtantsur> lucasagomes, enabled_drivers in Ironic is a completely different beast, e.g. they all are independent
<lucasagomes> and if one wants to do the default + plugins... perhaps they should script it?
* lucasagomes thinks
<lucasagomes> dtantsur, right, anyway it's a white list
<dtantsur> lucasagomes, e.g. if I ever split essential plugin into 2, people will get broken. that can't happen with Ironic. but well, I'm starting to agree that I don't have compelling enough reason for this option...
<lucasagomes> dtantsur, the good thing about this option is that you still can have the old behavior with processing_hooks only
<lucasagomes> if u just leave the append_processing_hooks empty
<dtantsur> yep, it's pure opt-in
<lucasagomes> so yeah, I don't have a strong opnion about it either. It just looks a bit odd to have 2 options to enable hooks
<lucasagomes> dtantsur, plus the other that the hooks are specified matters right?
<dtantsur> lucasagomes, yep
<lucasagomes> so sometimes one wnat to keep the default hooks, but he has a custom hook that should run before everything else
<lucasagomes> and that option won't actually help him
<lucasagomes> because it just appends to the end of the list
<lucasagomes> devananda, g'night
<dtantsur> lucasagomes, actually I was thinking about prepend_processing_hooks too :D
<lucasagomes> heh
<dtantsur> but yeah, maybe I'm overengineering things...
<lucasagomes> dtantsur, yeah maybe we should brainstorm see what would be a good way to do it
<lucasagomes> I think that, if one wants to change the hooks etc he could script it
<lucasagomes> to apply the configuration with the hooks and order he wants

One of ideas: https://review.openstack.org/#/c/170535/

[Sam Betts (sambetts)]

I had a quick browse through this bug, and I came up with this as a solution for including both prepending and appending hooks:

In the config you'd have two config options:

    default_processing_hooks = ramdisk_error,scheduler,validate_interfaces

    processing_hooks = $defaults

In the code '$defaults' would get resolved to the values stored in default_processing_hooks. If a operator wanted to add their own hooks before or after the defaults they could like:

   processing_hooks = prehook,$defaults,posthook,secondposthook

What do you think? This was just my initial thoughts after reading the bug report and the comments on the linked patch.

[Dmitry Tantsur (divius)]

It sounds nice. Oslo config already have variables support btw, but last time I checked it only supported using variables from DEFAULT section. So we might need to put default_processing_hooks there, then we'll be able to use processing_hooks = $default_processing_hooks without any effort.