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

Use SupportsFeatureMixin for querying VM for "resize" operation #9683

Merged
merged 2 commits into from
Jul 21, 2016

Conversation

gauravaradhye
Copy link
Contributor

@gauravaradhye gauravaradhye commented Jul 8, 2016

Purpose:
SupportsFeatureMixin provides convenient way to specify if a particular provider has support for a feature. This pull request removes validate_resize (old usage) and makes checking feature support by calling supports_resize possible.

Relevant previous PRs:
Similar changes in:

  1. https://github.com/h-kataria/manageiq/pull/8/files
  2. https://github.com/ManageIQ/manageiq/pull/9271/files

Steps for Testing/QA

Rspec output:
bundle exec rspec spec/models/manageiq/providers/openstack/cloud_manager/vm_spec.rb

Randomized with seed 23687
.........................

Finished in 3.97 seconds (files took 5.69 seconds to load)
25 examples, 0 failures

Randomized with seed 23687

@chessbyte chessbyte changed the title [WIP] Use SupportsFeatureMixin for querrying VM for resize operation [WIP] Use SupportsFeatureMixin for querying VM for resize operation Jul 8, 2016
@@ -1,4 +1,5 @@
class ManageIQ::Providers::CloudManager::Vm < ::Vm
include SupportsFeatureMixin
Copy link
Member

Choose a reason for hiding this comment

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

This is already included in VmOrTemplate parent class

@durandom
Copy link
Member

durandom commented Jul 8, 2016

Good first shot :)
Are there any other usages of validate_resize in the code?

@gauravaradhye
Copy link
Contributor Author

Thanks! There are no usages of validate_resize but some similar methods such as validate_resize_confirm and validate_resize_revert. Should I go ahead removing those too?

@durandom
Copy link
Member

durandom commented Jul 8, 2016

validate_resize_confirm and validate_resize_revert.

looks like those are only used by the service models. So, no, dont touch them.

But could you change this line to expose :supports_resize?

@@ -187,6 +187,8 @@ class VmOrTemplate < ApplicationRecord
alias_method :parent_cluster, :ems_cluster
alias_method :owning_cluster, :ems_cluster

supports_not :resize, :reason => _("Resize Operation is not available for VM or Template.")
Copy link
Member

Choose a reason for hiding this comment

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

as this is unlikely to be called on VmOrTemplate and its not really a reason other than it's unsupported, I would drop the reason.

@durandom
Copy link
Member

@gauravaradhye could you limit this PR to refactor only the resize operation?
That means, we keep validate_vm_control until it's not used anymore and remove it in its own PR.
This might sound a bit complictated, but makes the refactoring a) much safer b) easier to backport.
E.g. if we need to backport only the resize refactoring, we only need to cherry-pick this PR.

Also, please address the rubocop issues. It's good to run rubocop before committing 😄

@gauravaradhye
Copy link
Contributor Author

@durandom yes makes sense. I will update it with required changes. Also, do we have any document for coding guidelines for dev other than checking with rubocop?

@durandom
Copy link
Member

@gauravaradhye https://github.com/ManageIQ/guides thats all I know of

@gauravaradhye gauravaradhye changed the title [WIP] Use SupportsFeatureMixin for querying VM for resize operation Use SupportsFeatureMixin for querying VM for "resize" operation Jul 14, 2016
@durandom
Copy link
Member

@gauravaradhye please rebase the PR and squash the commits into one

supports :resize do
msg = validate_vm_control
unsupported_reason_add(:resize, msg[1]) unless msg.nil?
unsupported_reason_add(:resize, _("The Instance cannot be resized, current state has to be active or shutoff.")) \
Copy link
Member

Choose a reason for hiding this comment

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

dont wrap lines with \
if they are too long use

unless ...
  add
end

@@ -6,7 +6,7 @@ class MiqAeServiceManageIQ_Providers_Openstack_CloudManager_Vm < MiqAeServiceVmC
expose :resize_confirm, :override_return => nil
expose :resize_revert, :override_return => nil

expose :validate_resize
expose :supports_resize?
Copy link
Member

Choose a reason for hiding this comment

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

@gmcculloug I guess for backwards compatability we should still have validate_resize available?
can we do so by adding this?

def validate_resize
  {:available => supports_resize?, :message => unsupported_reason(:resize)}
end

in what context are those methods evaluated?

Copy link
Member

Choose a reason for hiding this comment

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

@durandom That's the nice thing about automate, you never really know if/when the methods are used since it is referenced from user code. 😦 This is pretty new stuff (PR #7922 was merged in April), I do not know of anyone using it.

The suggested solution of adding the validate_resize method would work.

Note: If it helps you can also rename the backend method and redirect automate to the name method using :method => <new_method_name>.
lib/miq_automation_engine/service_models/miq_ae_service_vm_or_template.rb#L19

Copy link
Member

Choose a reason for hiding this comment

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

@gmcculloug thanks, I think we go with adding the wrapper method. 👍 for pointing out the alternative.

@gauravaradhye so, please add this wrapper and remove the expose call altogether

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@durandom So should I keep the expose validate_resize statement as it is and change the validate_resize method body to internally use supports_resize?

Copy link
Member

Choose a reason for hiding this comment

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

  • keep expose: supports_resize?
  • add the method from the first comment

@gauravaradhye
Copy link
Contributor Author

Confirmed there are no old comments with mentioning "validate_resize". No code changes needed.

@durandom
Copy link
Member

@gauravaradhye if the automate thing is fixed, this is good to go

@gauravaradhye
Copy link
Contributor Author

gauravaradhye commented Jul 18, 2016

Included the validate_resize method in cloud_manager/vm.rb and kept the expose :supports_resize? statement as it is.

Did not include validate_resize method back in app/models/manageiq/providers/openstack/cloud_manager/vm/resize.rb because the base class cloud_manager/vm.rb should take care of it.

@durandom
Copy link
Member

Did not include validate_resize method back in app/models/manageiq/providers/openstack/cloud_manager/vm/resize.rb because the base class cloud_manager/vm.rb should take care of it.

Why? This is supposed to be removed?

@gauravaradhye
Copy link
Contributor Author

@durandom I have kept validate_resize method in only base class as it would be necessary for automate code that might be calling it. If it is called on subclasses, then the base class method will be called which will internally call the supports_resize method of subclass.

@durandom
Copy link
Member

I have kept validate_resize method in only base class as it would be necessary for automate code that might be calling it.

This compatibility layer should be in the automate code. miq_ae_service_manageiq-providers-openstack-cloud_manager-vm.rb

@gauravaradhye
Copy link
Contributor Author

@durandom Moved code as required.

@durandom
Copy link
Member

ok, also please address the comments in app/models/manageiq/providers/openstack/cloud_manager/vm/resize.rb

@miq-bot
Copy link
Member

miq-bot commented Jul 20, 2016

Checked commits gauravaradhye/manageiq@4e76048~...ae98632 with ruby 2.2.5, rubocop 0.37.2, and haml-lint 0.16.1
7 files checked, 0 offenses detected
Everything looks good. 👍

@chessbyte
Copy link
Member

@durandom will merge after your 👍

@durandom
Copy link
Member

👍 looks great. @chessbyte merge?

@miq-bot add_labels darga/no

@chessbyte chessbyte merged commit c4271de into ManageIQ:master Jul 21, 2016
@chessbyte chessbyte added this to the Sprint 44 Ending Aug 1, 2016 milestone Jul 21, 2016
@durandom
Copy link
Member

🎉 @gauravaradhye congrats for your second merged PR, keep them rolling in 😄

included do
supports :resize do
unsupported_reason_add(:resize, unsupported_reason(:control)) unless supports_control?
unless %w(ACTIVE SHUTOFF).include?(raw_power_state)
Copy link
Contributor

@himdel himdel Mar 5, 2018

Choose a reason for hiding this comment

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

supports_resize? is never true now, because %w(ACTIVE SHUTOFF) is ["ACTIVE", "SHUTOFF"] and not [ACTIVE, SHUTOFF] which would (actually still not) evaluate to the right %w(on off) array which corresponds to the actual values :).

But [ACTIVE, SHUTOFF] doesn't work within supports..., it won't find the constant.

So... I suggest fixing this to just say %w(on off) and not relying on provider-specific constants :).

@gauravaradhye , @durandom Can you take care of this please? :)

(created ManageIQ/manageiq-providers-openstack#246)

EDIT: never mind, I was wrong, sorry

Copy link
Member

Choose a reason for hiding this comment

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

@himdel - sorry, neither @gauravaradhye nor me are working on the codebase anymore. I'm sure one of the openstack provider maintainers can tackle that. I'm still avail for questions :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, thanks for the heads up :) don't worry about it, the issue is there, and if it stays there I'll just create a PR one of those days ;). Good luck :)

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.

6 participants