Skip to content
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

Merged
merged 1 commit into from
Jan 15, 2021

Conversation

Fryguy
Copy link
Member

@Fryguy Fryguy commented Jan 12, 2021

@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

$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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

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:

#20950 (comment)

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?

@Fryguy
Copy link
Member Author

Fryguy commented Jan 12, 2021

The biggest change here is

  • now only the base loggers are set up initially when Vmdb::Loggers.init is called here
  • plugin loggers are not set up until Vmdb::Plugins.init is called here
  • All of the config changes are then applied to all loggers here

@Fryguy
Copy link
Member Author

Fryguy commented Jan 12, 2021

@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.

lib/vmdb/loggers.rb Outdated Show resolved Hide resolved
@Fryguy Fryguy force-pushed the pluggable_loggers branch from 51f25c7 to 5796a4e Compare January 13, 2021 21:32
@Fryguy
Copy link
Member Author

Fryguy commented Jan 13, 2021

@agrare Updated with your suggestion...WDYT?

@Fryguy
Copy link
Member Author

Fryguy commented Jan 13, 2021

Cool....I'll have to create a chain of PRs for all of the plugins, after which I can un-WIP

@jrafanie
Copy link
Member

@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

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.

@Fryguy
Copy link
Member Author

Fryguy commented Jan 13, 2021

Have you tried a cross repo with the plugin changes?

Not yet...I have to make like 20 PRs to all of the plugins first.

@Fryguy Fryguy force-pushed the pluggable_loggers branch from 5796a4e to 092d277 Compare January 13, 2021 22:38
@jrafanie
Copy link
Member

Not yet...I have to make like 20 PRs to all of the plugins first.

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.

@Fryguy Fryguy force-pushed the pluggable_loggers branch from 092d277 to 3ff38e7 Compare January 13, 2021 22:42
@Fryguy
Copy link
Member Author

Fryguy commented Jan 13, 2021

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.

@Fryguy Fryguy force-pushed the pluggable_loggers branch from 3ff38e7 to 2f6cbdd Compare January 13, 2021 22:50
@Fryguy
Copy link
Member Author

Fryguy commented Jan 13, 2021

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 😆

@Fryguy Fryguy force-pushed the pluggable_loggers branch from 2f6cbdd to 297aa6f Compare January 14, 2021 17:44
@Fryguy Fryguy requested a review from NickLaMuro as a code owner January 14, 2021 17:44
@miq-bot
Copy link
Member

miq-bot commented Jan 14, 2021

Checked commit Fryguy@297aa6f with ruby 2.6.3, rubocop 0.82.0, haml-lint 0.35.0, and yamllint
4 files checked, 0 offenses detected
Everything looks fine. 🍰

@Fryguy
Copy link
Member Author

Fryguy commented Jan 14, 2021

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 😆

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.

@Fryguy
Copy link
Member Author

Fryguy commented Jan 14, 2021

@miq-bot cross_repo_test ManageIQ/manageiq-providers-amazon#675, manageiq-providers-azure, manageiq-api, manageiq-ui-classic

miq-bot pushed a commit to ManageIQ/manageiq-cross_repo-tests that referenced this pull request Jan 14, 2021
@Fryguy Fryguy changed the title [WIP] Move logger initialization and configuration into plugins Move logger initialization and configuration into plugins Jan 14, 2021
@miq-bot miq-bot removed the wip label Jan 14, 2021
@Fryguy
Copy link
Member Author

Fryguy commented Jan 14, 2021

@jrafanie @agrare Cross repo is green

Copy link
Member

@NickLaMuro NickLaMuro left a 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
Copy link
Member

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")
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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
Copy link
Member

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:

#20950 (comment)

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.

Copy link
Member Author

@Fryguy Fryguy Jan 14, 2021

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 %>)
Copy link
Member

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.

@Fryguy
Copy link
Member Author

Fryguy commented Jan 14, 2021

@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.

@NickLaMuro
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants