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

Pluggable automate domains #11083

Merged
merged 6 commits into from
Dec 16, 2016
Merged

Pluggable automate domains #11083

merged 6 commits into from
Dec 16, 2016

Conversation

bdunne
Copy link
Member

@bdunne bdunne commented Sep 7, 2016

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:

def vmdb_plugin?
  true
end

@Fryguy
Copy link
Member

Fryguy commented Sep 7, 2016

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

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.

Copy link
Member

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)

@Fryguy
Copy link
Member

Fryguy commented Sep 7, 2016

@durandom Please review with respect to the plugins module added here...I think that might overlap a bit with what you were doing in #10944 with the same end goal of not having the plugin itself specify the descendat_loader paths.

@chessbyte
Copy link
Member

/cc @blomquisg @gmcculloug

@durandom
Copy link
Member

durandom commented Sep 8, 2016

@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. Amazon::Provider.engine . That also enforces gems to subclass the Provider class, which now somewhat optional :)

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.

@bdunne
Copy link
Member Author

bdunne commented Sep 8, 2016

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

@durandom
Copy link
Member

durandom commented Sep 8, 2016

plugins that provide specific features, but not a provider subclass

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.

@bdunne
Copy link
Member Author

bdunne commented Sep 8, 2016

I have two current use cases where I would like to see that happen soon.

  1. Extract the default ManageIQ automate domain to its own repo
  2. Downstream productization (provide an automate domain and a few non-provider model subclasses)

@@ -0,0 +1,3 @@
Rails.application.railties.each do |railtie|
Vmdb::Plugins.instance.register_provider_plugin(railtie) if railtie.try(:manageiq_provider_plugin?)
Copy link
Member

@durandom durandom Sep 9, 2016

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

@durandom
Copy link
Member

durandom commented Sep 9, 2016

@bdunne ok, then the naming of Vmdb::Plugins also makes sense, because its not only providers that are plugged.

So I favor this approach over mine in #10944
It would be great if you add the addition based on the namespace, too. Because I want to it to be super easy to create a provider gem :)

@durandom
Copy link
Member

@bdunne wdy think about my #11083 (comment) ?
I'd like to get this in soon, to continue working on moving settings.yml over to the provider repo.

Copy link
Member

@durandom durandom left a 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 :(

@bdunne bdunne force-pushed the pluggable_automate branch 2 times, most recently from ebefd4f to 9af98a0 Compare September 16, 2016 16:20
@bdunne
Copy link
Member Author

bdunne commented Sep 16, 2016

I added the change @durandom suggested to reduce engine setup knowledge and changed to register_vmdb_plugin since it is not necessarily a provider

Copy link
Member

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

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?

@durandom
Copy link
Member

@miq-bot assign Fryguy

@Fryguy merge?

@gmcculloug
Copy link
Member

cc @mkanoor

@durandom
Copy link
Member

durandom commented Oct 4, 2016

@bdunne do you want this in euwe?

@bdunne bdunne added the euwe/yes label Oct 4, 2016
@bdunne
Copy link
Member Author

bdunne commented Oct 6, 2016

🐢

@Fryguy
Copy link
Member

Fryguy commented Oct 26, 2016

#12221 is merged.

@miq-bot
Copy link
Member

miq-bot commented Oct 26, 2016

<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush.

@miq-bot
Copy link
Member

miq-bot commented Dec 13, 2016

<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush.

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

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

Copy link
Member

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 :)

@miq-bot
Copy link
Member

miq-bot commented Dec 15, 2016

<pr_mergeability_checker />This pull request is not mergeable. Please rebase and repush.

@miq-bot
Copy link
Member

miq-bot commented Dec 15, 2016

Checked commits bdunne/manageiq@633197d~...8ada346 with ruby 2.2.5, rubocop 0.37.2, and haml-lint 0.16.1
8 files checked, 0 offenses detected
Everything looks good. 🍰

@Fryguy Fryguy merged commit 44bfe35 into ManageIQ:master Dec 16, 2016
@Fryguy Fryguy added euwe/no and removed euwe/yes labels Dec 16, 2016
@Fryguy Fryguy added this to the Sprint 51 Ending Jan 2, 2017 milestone Dec 16, 2016
@bdunne bdunne deleted the pluggable_automate branch December 16, 2016 16:15
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.

8 participants