action #6192
closed
[easy hack] Move auth plugin configuration parsing back to auth plugin
Added by oholecek over 9 years ago.
Updated almost 6 years ago.
Category:
Feature requests
Description
OpenQA config parsing loads only keys it knows about, thus other plugins can't extend this by their keys.
However, in case of more plugins are added with their respective configuration, we may want to enable plugin parsing to avoid cluttering the main method.
Possible ways are to load all keys in configuration file or call plugin config method as soon as we know which plugin to load during the configuration file parsing.
- Target version changed from Easy hacks to future
as mentioned on irc os-fctry: [Wednesday, 30 November 2016] [15:34:56 CET] anyone minds if I replace the milestone "easy hacks" with a keyword in subject line? IMHO it's not a proper milestone and not at all useful for the roadmap
- Subject changed from Move auth plugin configuration parsing back to auth plugin to [easy hack] Move auth plugin configuration parsing back to auth plugin
- Assignee set to EDiGiacinto
just FYI in case you did not know yet. A ticket of "low" priority and target version "future" means so far we did not really have a plan to do this. If some voluntary contributor wants to work on it of course it's appreciated. A ticket query like this, i.e. all open tickets sorted by priority, is corresponding more to where we see the necessity to work on. this query is another entry point: Listing all open tickets sorted by milestone, i.e. which ones have been planned to be completed first. In any case, just FYI, not prescribing what ticket you should work on and which not. In the end, another entry point to the ticket backlog is: Start with the tickets you can resolve the fastest. So far you have been already quite good at it :-)
Thanks for the links and the heads-up! so far i'm trying to work on the tickets that i believe i can fit in - just until i feel a bit more confident on the codebase and i have the proper tools to reproduce the bugs/tickets/scenarios. Wrt this specific issue, i thought would be handy to have in the code - because in such way we could demand configurations to plugins (and hence, be more dynamic)
- Status changed from New to Feedback
- Status changed from Feedback to Resolved
- Target version changed from future to future
Also available in: Atom
PDF