-
Notifications
You must be signed in to change notification settings - Fork 896
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
Pluggable automate domains #11083
Pluggable automate domains #11083
Conversation
@durandom Please also review. |
def self.reset_domains_from_provider_gems | ||
provider_gems = Vmdb::Plugins.instance.provider_plugins | ||
provider_gems.each do |provider_gem| | ||
domain_bucket = provider_gem.root.join("db", "fixtures", "ae_datastore") |
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.
👍 on convention over configuration here.
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.
Wondering if this should be moved out to a common method, since the "built-in" domains are also in the same path (thus duplicating the path generation code)
@bdunne have you checked my approach in #10944 ? I find it more intuitive by asking a Provider subclass if its an engine and then getting that engine by e.g. Also see my comment here I think its safe to assume all providers are under that namespace, so it's one method less to define. |
@durandom The only problem that I see with that approach is if we want to have plugins that provide specific features (like an automate domain and some models), but not a provider subclass, you won't find the plugin in the same way. |
Is that going to happen in the near term? If not, I would go with simpler approach and with adding less boilerplate code baggage to the provider gems. |
I have two current use cases where I would like to see that happen soon.
|
@@ -0,0 +1,3 @@ | |||
Rails.application.railties.each do |railtie| | |||
Vmdb::Plugins.instance.register_provider_plugin(railtie) if railtie.try(:manageiq_provider_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.
How about adding a convention like approach here too:
if railtie.class.name.start_with? "ManageIQ::Providers::" || railtie.try(:manageiq_provider_plugin?)
this way all engines under this namespace get registered automatically
@bdunne wdy think about my #11083 (comment) ? |
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.
+1 for the Vmdb::Plugins
idea. Would be great to auto-registers Rails engines under the ManageIQ::Providers
Namespace, but I can do this in a follow up PR too.
I cant comment on the reset_domains..
part though :(
ebefd4f
to
9af98a0
Compare
I added the change @durandom suggested to reduce engine setup knowledge and changed to |
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.
looks good to me.
restore_attrs_for_domains(saved_attrs) | ||
reset_default_namespace | ||
end | ||
|
||
def self.reset_domains_from_provider_gems | ||
provider_gems = Vmdb::Plugins.instance.vmdb_plugins |
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.
only minor, but maybe bring this and the method name in line with vmdb_plugins
which are not necessarily providers?
cc @mkanoor |
@bdunne do you want this in euwe? |
🐢 |
#12221 is merged. |
<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush. |
9af98a0
to
048972a
Compare
<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush. |
a2a0ea8
to
012e5ac
Compare
c32b309
to
9533b10
Compare
@@ -12,6 +12,10 @@ def initialize(path) | |||
@name = config.fetch_path("object", "attributes", "name") | |||
end | |||
|
|||
def system? | |||
@system ||= config.fetch_path("object", "attributes", "source") == "system" |
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.
not necessarily bad, but if this evaluates to false
it'll be evaluated next time it's called - making the memoization useless. Maybe just drop @system
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.
hmm, looks like this commit isnt in the PR anymore, so ignore :)
<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush. |
9533b10
to
8339493
Compare
Extra domains may cause test failures because of changed behavior
8339493
to
8ada346
Compare
Checked commits bdunne/manageiq@633197d~...8ada346 with ruby 2.2.5, rubocop 0.37.2, and haml-lint 0.16.1 |
Allow provider plugins to carry their own automate domains. When resetting domains, those should be included in the reset.
If the plugin doesn't start with "ManageIQ::Providers::", the engine.rb should include: