-
Notifications
You must be signed in to change notification settings - Fork 898
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move logger initialization and configuration into plugins #20950
Conversation
b552043
to
51f25c7
Compare
$vcloud_log = create_multicast_logger(path_dir.join("vcloud.log")) | ||
$vim_log = create_multicast_logger(path_dir.join("vim.log")) | ||
$remote_console_log = create_multicast_logger(path_dir.join("remote_console.log")) | ||
# TODO: Move this into the manageiq-api plugin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is because of https://github.com/ManageIQ/manageiq-api/blob/5683d9ebd1d708d0be3257296d081595c203f1ac/lib/manageiq/api/engine.rb#L9-L18, which I can solve eventually, but am skipping for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that this comment is here prior to the suggestion by @jrafanie to only do a subset of loggers first:
And this is less relevant of a "FYI" now that we are really only moving out two of the loggers for this first pass, correct?
@jrafanie Can you also review here? I want to make sure that some of the primordial cases for having logs available aren't broken (like running rake tasks that need a logger, but not Rails env), but I'm not sure which one is a good candidate. |
51f25c7
to
5796a4e
Compare
@agrare Updated with your suggestion...WDYT? |
Cool....I'll have to create a chain of PRs for all of the plugins, after which I can un-WIP |
It looks good so far. Have you tried a cross repo with the plugin changes? I think that will cover a lot of these cases including some of the rake tasks. |
Not yet...I have to make like 20 PRs to all of the plugins first. |
5796a4e
to
092d277
Compare
hehe Maybe you can try undoing some of the changes locally so only 1 or 2 plugins opt-in to this new behavior? I could be missing something but it seems like you could have it either internal/external just for sanity testing and then swap all of the external plugins to external for the final test and merge. |
092d277
to
3ff38e7
Compare
Yeah that's not a bad idea for the first pass. I wanted to avoid having to make a pair of PRs per plugin, but I could make this PR pass with a couple of plugins, then a follow-up PR with all of the rest. |
3ff38e7
to
2f6cbdd
Compare
Ok, @jrafanie Updated so that the only extracted logger is $aws_log. Ironically, I might have to undo that because I think $aws_log is used by FileDepotS3, so I might have to choose a different logger 😆 |
2f6cbdd
to
297aa6f
Compare
Checked commit Fryguy@297aa6f with ruby 2.6.3, rubocop 0.82.0, haml-lint 0.35.0, and yamllint |
I went a different approach and ensured that the logger was created. It's effectively a no-op, but in the future if we remove the provider plugin, then this code will continue to work. |
@miq-bot cross_repo_test ManageIQ/manageiq-providers-amazon#675, manageiq-providers-azure, manageiq-api, manageiq-ui-classic |
From Pull Request: ManageIQ/manageiq#20950
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am good with this concept. I have a few concerns, but honestly I think they are minor and/or probably not relevant.
@@ -106,7 +113,7 @@ def self.apply_config(config) | |||
nil | |||
end | |||
|
|||
def self.configure_external_loggers | |||
private_class_method def self.configure_external_loggers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Crystal fanboy-ism coming into play here... 😏 💎
@@ -11,5 +11,13 @@ def self.vmdb_plugin? | |||
def self.plugin_name | |||
_('<%= plugin_human_name %>') | |||
end | |||
|
|||
def self.init_loggers | |||
$<%= plugin_name %>_log ||= Vmdb::Loggers.create_logger("<%= plugin_name %>.log") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we default this line to be commented out to start? Just seems like it makes sense to have this opt in to start, and if a more isolated logger is required by the plugin author, the interface is easily adjusted in the code base.
Just trying to avoid "log-splosion" in the log/
dir, with a bunch of unused files and debugging turns into checking a bunch of files that in fact are just empty. But possibly this is a necessary concern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Coincidentally, just talked about this with @agrare and yeah I agree. I am going to change this to commented out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think the ideal would be command line option for the provider generator like:
rails generate manageiq:plugin [--logger]/[--no-logger]
And then this could become:
<% if options[:logger] -%>
def self.init_loggers
...
end
<% end -%>
@@ -11,5 +11,13 @@ def self.vmdb_plugin? | |||
def self.plugin_name | |||
_('<%= plugin_human_name %>') | |||
end | |||
|
|||
def self.init_loggers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was using this comment (and any other ones as well) for reference prior to giving my own thoughts:
But one downside to this approach is that a plugin author can technically do whatever the heck they feel like in this section, and it could have nothing to do with loggers
. Highly doubt it will be a problem, but just something that came to mind as I was looking at this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we want them to do whatever they want (like set up custom loggers for client gems or something)
end | ||
|
||
def self.apply_logger_config(config) | ||
Vmdb::Loggers.apply_config_value(config, $<%= plugin_name %>_log, :level_<%= plugin_name %>) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you go with my suggestion above for commenting the contents of init_loggers
out, you would probably want to do that here as well.
@agrare @jrafanie @NickLaMuro Acutally, I'd like to do the commenting/removal of #20950 (comment) in the follow up PR when I blast this out to all of the other plugins. @agrare and I will be reviewing each PR and I think we'll have a better decision about defaulting to on or off based on our analysis of those PRs. |
I am good with that. Seems like a good time/plan to determine if what I am saying is an edge case or a common occurrence. I am cool with moving this forward as is. |
@agrare Please review.
This PR only accounts for the Amazon provider (ManageIQ/manageiq-providers-amazon#675) in order to work out any kinks before I blast out PRs to all of the individual plugins.
Part of #19440