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

consolidate supported storage types #22258

Merged
merged 4 commits into from
Dec 7, 2022
Merged

Conversation

kbrock
Copy link
Member

@kbrock kbrock commented Dec 1, 2022

needed for:

I only need the first change, which is low risk. The second one is a clean up that may not be necessary or deemed too risky.

Change:

  1. Rename method supports? to storage_type_supported_for_ssa?
    I introduced a conflict with SupportsFeatureMixin in Cap&U split up capture_infra_targets to allow tuning #9447
  2. Make the list of supported storage_type values consistent.
    The method above was used in metrics capture Storage.scan and capture_storage_targets
    Similar but different lists are found in vm_scan, and Vm.path.

@agrare Regarding the second item:

  • Is there a reason why those 3 lists of supported storage_type values should be different?
  • What is the best way to determine the proper list? (I chose to include all)
storage_type Storage.scan Vm.path vm_scan
VSAN y y
VMFS y y y
NAS y y
NFS y y y
NFS41 y y y
ISCSI y y
DIR y
FCP y y
CSVFS y y
NTFS y y
GLUSTERFS y y

/cc @nasark

@kbrock kbrock requested review from agrare and Fryguy as code owners December 1, 2022 01:36
@kbrock kbrock force-pushed the storage_supports branch 3 times, most recently from 4770c21 to c6e97ef Compare December 1, 2022 19:13
@kbrock
Copy link
Member Author

kbrock commented Dec 1, 2022

update:

  • fixed spacing cop
  • fixed constant/array cop (sorry, took a few tries)
  • fixed specs to be consistent
  • fixed typo for storage_type vs store_type

@@ -78,7 +78,7 @@ def capture_host_targets(ems)
# @return [Array<Storage>] supported storages
# hosts preloaded storages and tags
def capture_storage_targets(hosts)
hosts.flat_map(&:storages).uniq.select { |s| Storage.supports?(s.store_type) & s.perf_capture_enabled? }
hosts.flat_map(&:storages).uniq.select { |s| s.storage_type_supported? & s.perf_capture_enabled? }
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 a little confused by this at first, I think because it sounds like we won't create the storage if it isn't supported.

I think this would more accurately be described as storage_type_supported_for_scan? or _for_ssa?. Maybe even add the storage type check into supports?(:smartstate_analysis) which we already have?

@kbrock
Copy link
Member Author

kbrock commented Dec 1, 2022

update:

  • renamed storage_type_supported? to storage_type_supported_for_ssa?

app/models/vm_or_template.rb Outdated Show resolved Hide resolved
@kbrock
Copy link
Member Author

kbrock commented Dec 2, 2022

I think this would more accurately be described as storage_type_supported_for_scan? or _for_ssa?. Maybe even add the storage type check into supports?(:smartstate_analysis) which we already have?

@agrare I'll look into:

class Storage
  supports :smartstate_analysis do
    if !ext_management_system&.class&.supports?(:smartstate_analysis) || !storage_type_supported_for_ssa?
      _("Smartstate Analysis cannot be performed on selected Datastore")
    elsif !ext_management_system&.authentication_status_ok?
      _("There are no EMSs with valid credentials for this Datastore")
    end
  end
end

Do you want explicit wording for it?
I'll look to see if we can remove some of these checks if we have a not supports for smartstate

@agrare
Copy link
Member

agrare commented Dec 5, 2022

Do you want explicit wording for it?

@kbrock up to you, if we can give a more specific reason why we don't support it without much downside I don't see why not

We are triggering queue_signal for every flow, both for error and success cases.
So detecting if the queue_signal is called doesn't mean anything.

The positive cases were passing because either the vms were not updated or it was not calling dispatch at all.
The negative cases were passing because an authorization was missing, which is not actually what was under test.

The host now has authentication so we can do the tests
the ems now has authentication so we can do more tests
The vms are updated properly (it was not saving the storage before)
The vms all have an ems (so they have authentications are scannable)
The storages and repo_storage have an ems
The tests are stating the signal they are expecting

(not necessary)
removed constants from specs (constants are defined in the global, not just in this spec)
reference ems instead of ems id in factory
…eatureMixin conflict

BTW/ This method name is a little tricky.

The field is store_type
but the constant is SUPPORTED_STORAGE_TYPES
The listed of supported storage types was different between metrics capture, vm_scan, and vm path
This made them consistent.
I had replaced storage.storage_type_supports_ssa? calls to just use supports(:smartstate_analysis)
but I wasn't sure if that was correct for a few.

But I did keep ems authentication changes - they seemed like they may make introduce some false negatives
in some areas of the code
@kbrock
Copy link
Member Author

kbrock commented Dec 6, 2022

update

  • ensured objects created by factory/helper had ems references

Sorry took so many tries, the errors were not always obvious what was breaking the tests.

@@ -78,7 +78,7 @@ def capture_host_targets(ems)
# @return [Array<Storage>] supported storages
# hosts preloaded storages and tags
def capture_storage_targets(hosts)
hosts.flat_map(&:storages).uniq.select { |s| Storage.supports?(s.store_type) & s.perf_capture_enabled? }
Copy link
Member Author

Choose a reason for hiding this comment

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

so while we introduced storage_type_supported_for_ssa?, I rolled it into supports?(:smartstate_analysis) and basically removed all the calls.

Here, I felt perf_capture_enabled? wasn't part of supports, so I kept this separate.

@miq-bot
Copy link
Member

miq-bot commented Dec 6, 2022

Checked commits kbrock/manageiq@dbf6c93~...ac06484 with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint
10 files checked, 0 offenses detected
Everything looks fine. 🍪

@agrare agrare merged commit 28fa0a6 into ManageIQ:master Dec 7, 2022
@kbrock kbrock deleted the storage_supports branch December 7, 2022 14:33
kbrock added a commit to kbrock/manageiq that referenced this pull request Dec 9, 2022
By default, a storage should be valid for smart state
Sure, it also needs an ems and others, but we definitely need a good store_type value

This is a followup to the recent supports change ManageIQ#22258 / 28fa0a6
GilbertCherrie pushed a commit to GilbertCherrie/manageiq that referenced this pull request Jul 7, 2023
By default, a storage should be valid for smart state
Sure, it also needs an ems and others, but we definitely need a good store_type value

This is a followup to the recent supports change ManageIQ#22258 / 28fa0a6
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.

3 participants