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

Add features based on supported_api_versions to RedHat provider #11418

Merged
merged 6 commits into from
Oct 13, 2016

Conversation

borod108
Copy link

@borod108 borod108 commented Sep 21, 2016

Using the SupportedFeaturesMixin to set features that are supported by the RedHat provider based on the API versions.
Using the OvirtSDK4 Probe to find which API versions are supported by the server.
This patch is dependant on OvirtSDK4 4.0.2

@chessbyte chessbyte changed the title Addind features basd on supported_api_versions to RedHat provider Add features based on supported_api_versions to RedHat provider Sep 21, 2016
@borod108
Copy link
Author

borod108 commented Sep 22, 2016

Please note rubocop is houting mainly because I moved existing code and it does not like the code that existed.
@blomquisg can you please take a look?
This should go in the next release so there are only 2 weeks to go, and there are at least 2 other patches based on this. Thank you!
@jhernand I would be very grateful for a review.

end

def cache_key
"REDHAT_EMS_CACHE_KEY_#{id}"
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use OVIRT instead of REDHAT ?

Copy link
Author

Choose a reason for hiding this comment

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

We can, but in the source code all the code related to oVirt is under a folder and name space named "redhat" that is why I used REDHAT. Considering this do you still think it should be OVIRT?

%w(default metrics)
end

class Cacher
Copy link
Contributor

Choose a reason for hiding this comment

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

I find this a bit over engineered. Do we really need this class? Can't we just call Rails.cache.read and Rails.cache.write directly?

Copy link
Author

Choose a reason for hiding this comment

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

@jhernand well I actually tried that at first, then wrote the spec, then re factored, the reason being that because of the need to rebuild the cache based on whether it is older then the last refresh (that is what we discussed with you when designing this) it is not a one liner it require couple of extra methods which I do not think belong in the class directly.
Second point is that this seems to be the first place Rails.cache is used outside of specs. While I think this is the right way to go, perhaps there is a reason no one used it and it will have to change to use some other mechanism. In this case changing the code in the Cacher class which is independent of the infra_menager implementation will be easier.

def supported_auth_types
%w(default metrics)
end

def supports_authentication?(authtype)
Copy link
Member

Choose a reason for hiding this comment

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

It's not part of this PR, but this method will clash once there is a feature called authentication. Because the SupportsFeatureMixin will add a method supports_authentication? 😟

Maybe you can rename that in another PR?

Copy link
Author

Choose a reason for hiding this comment

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

Thank you! You are absolutely right. I will. Please tell me how to make sure that those PRs will be merged in the right order?

Copy link
Author

Choose a reason for hiding this comment

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

@durandom wait no! thats not true, it will only add methods for the symbols in api3_supported_features and api4_supported_features, https://github.com/ManageIQ/manageiq/pull/11418/files#diff-d6125c21d43685840429020f8c5a57aaR186
other methods will not be effected. So if someone adds "authentication" symbol there, then it might cause a problem. But rightly so - if its not supposed to support authentication from some API version then it should be addressed.

end
end

def supports_api_version?(version)
Copy link
Member

Choose a reason for hiding this comment

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

same here: supports_api_version? will clash with a feature called api_version

Copy link
Author

Choose a reason for hiding this comment

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

right, this one was actually added in this PR so I will just change it here.

require_nested :Refresher
require_nested :Template
require_nested :Vm
include_concern :ApiIntegration
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason of moving this to a module? I find it harder to review this way, because I dont know what actually changed.

Copy link
Author

Choose a reason for hiding this comment

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

I am not sure what to do with this, i mean I think it should definitely move to a separate module (actually I think it should be built differently and move to a different class all together) and I could not really work on this when it was all mixed. So I should have moved it first, open a PR on that and only then do the rest. But I did not. If its crucial I will do it now. Is it? @durandom

Copy link
Member

Choose a reason for hiding this comment

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

Well, its not crucial, but it makes it way easier to review and less error prone imho :)
If its not such a big deal and doesnt eat up too much time, yes, please.

I'd leave the connect methods in the manager class, because they are needed for with_provider_connection. But you sure can delegate that to an new class.

And yes, I'm all for proper separation of concerns and adding more classes than just stuffing code into modules.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, and I think such a refactoring PR would get merged pretty fast

Copy link
Author

Choose a reason for hiding this comment

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

@durandom ok added the PR: #11482
When its merged I will rebase this one over it.

end

def api4_supported_features
[:reconfigure_vms, :snapshots]
Copy link
Member

Choose a reason for hiding this comment

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

those would need to be added to SupportsFeatureMixin::QUERYABLE_FEATURES
Also those should already have some corresponding validate_ methods in the code, where the UI asks if the manager can handle this operation.

Copy link
Author

Choose a reason for hiding this comment

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

It is https://github.com/ManageIQ/manageiq/pull/11418/files#diff-0613648e8f7d7c13b5aeb5071c90f6d2R73
and the validate exists for the snapshot, and to be added after this patch for reconfigure_vms.


def supported_api_verions_from_sdk
with_provider_connection(:path => '', :version => 4, :skip_supported_api_validation => true) do |connection|
OvirtSDK4::Probe.probe(connection)
Copy link
Member

Choose a reason for hiding this comment

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

What does probe actually do?
Does it connect and the return a list like %w(v3 v4) ?
Can the result change over time?

Another way would be to store the result in something like models/advanced_settings.rb and check if thats correct upon validate_authentication. This is called whenever sombody clicks the button in the UI or when a worker is started.

Copy link
Author

Choose a reason for hiding this comment

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

Probe connects to server and by sending specific headers and analysing the response to them it figures out which versions of the API the oVirt server supports. Later it returns %w(3, 4)
The result can change over time if the server is upgraded. So the current mechanism is to recheck after every refresh. This is why it is cached.
What will be the advantages of using advanced_settings.rb?

Copy link
Member

Choose a reason for hiding this comment

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

What will be the advantages of using advanced_settings.rb?

  1. you dont need that caching stuff, but store it right in the db
  2. you can examine the setting from the UI

@borod108 borod108 force-pushed the rfe/add_cache_to_api_versions branch 3 times, most recently from 9cfbbbc to 6b81b96 Compare September 25, 2016 09:30
@miq-bot
Copy link
Member

miq-bot commented Sep 26, 2016

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

@borod108 borod108 force-pushed the rfe/add_cache_to_api_versions branch 2 times, most recently from 9a9aa8d to c866cf3 Compare September 27, 2016 07:51
@borod108
Copy link
Author

@miq-bot add-label euwe/yes

@miq-bot
Copy link
Member

miq-bot commented Sep 30, 2016

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

@miq-bot
Copy link
Member

miq-bot commented Oct 5, 2016

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

@borod108 borod108 force-pushed the rfe/add_cache_to_api_versions branch from f8c8ecc to 2ab0898 Compare October 5, 2016 14:30
@borod108 borod108 force-pushed the rfe/add_cache_to_api_versions branch 5 times, most recently from debe598 to 20e82c8 Compare October 12, 2016 09:27
@borod108 borod108 force-pushed the rfe/add_cache_to_api_versions branch from 20e82c8 to 1d55545 Compare October 12, 2016 09:28
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.

apart from reconfigure_vms still in SupportsFeatureMixin I'm good with the state of this.

@chrisarcand can you give your 👍 or 👎 on the cache thing?

@@ -76,12 +77,14 @@ module SupportsFeatureMixin
:provisioning => 'Provisioning',
:reboot_guest => 'Reboot Guest Operation',
:reconfigure => 'Reconfiguration',
:reconfigure_vms => 'Reconfigure Virtual Machines',
Copy link
Member

Choose a reason for hiding this comment

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

you'll want to remove this here too

Copy link
Author

Choose a reason for hiding this comment

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

right, was sure I did it, sorry.

@borod108 borod108 force-pushed the rfe/add_cache_to_api_versions branch from 1d55545 to 85aa509 Compare October 12, 2016 10:41
@chrisarcand
Copy link
Member

@durandom Will do; I'll be reviewing the caching stuff in earnest today around 10:30 CST (-600), about 3 hours from now, so this will be merged soon.

Copy link
Member

@chrisarcand chrisarcand left a comment

Choose a reason for hiding this comment

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

Looking at this closer, caching stuff is fine. My original thought is that the caching is so simple that you could roll your own simple cache but utilizing the Rails file store is fine and any changes I'd do are a little weird because of the fact that this is a mixin. Good for now 👍 :shipit:

@durandom
Copy link
Member

@chrisarcand thanks for the in depth look

@miq-bot assign @blomquisg

@blomquisg please merge

@miq-bot miq-bot assigned blomquisg and unassigned durandom Oct 12, 2016
@blomquisg blomquisg merged commit 855ea0f into ManageIQ:master Oct 13, 2016
@blomquisg blomquisg added this to the Sprint 48 Ending Oct 24, 2016 milestone Oct 13, 2016
@chessbyte
Copy link
Member

Euwe Backport details:

$ git log
commit b6913002e51033a6ca805caab1fa697d191ae023
Author: Greg Blomquist <blomquisg@gmail.com>
Date:   Thu Oct 13 02:26:11 2016 -0400

    Merge pull request #11418 from borod108/rfe/add_cache_to_api_versions

    Add features based on supported_api_versions to RedHat provider
    (cherry picked from commit 855ea0f3238617be8a931794c8783188329a1103)

chessbyte pushed a commit that referenced this pull request Oct 13, 2016
Add features based on supported_api_versions to RedHat provider
(cherry picked from commit 855ea0f)
jrafanie added a commit to jrafanie/manageiq that referenced this pull request Feb 20, 2017
https://bugzilla.redhat.com/show_bug.cgi?id=1423470

b691300 for PR ManageIQ#11418 was backported before
084ecea for PR ManageIQ#11018, causing some git context to bring
over the :terminate key twice.
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