-
Notifications
You must be signed in to change notification settings - Fork 899
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
Conversation
4770c21
to
c6e97ef
Compare
update:
|
@@ -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? } |
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.
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?
c6e97ef
to
c1aafde
Compare
update:
|
c1aafde
to
b9e045e
Compare
@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? |
b9e045e
to
bcae267
Compare
@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
bcae267
to
ac06484
Compare
update
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? } |
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.
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.
Checked commits kbrock/manageiq@dbf6c93~...ac06484 with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint |
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
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
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:
supports?
tostorage_type_supported_for_ssa?
I introduced a conflict with
SupportsFeatureMixin
in Cap&U split up capture_infra_targets to allow tuning #9447storage_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:
storage_type
values should be different?/cc @nasark