-
Notifications
You must be signed in to change notification settings - Fork 69
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
Collect customization_specs #614
Conversation
5e23239
to
8297e5e
Compare
@@ -377,4 +391,16 @@ def lazy_find_managed_object(managed_object) | |||
parent_collection = persister.vim_class_to_collection(managed_object) | |||
parent_collection.lazy_find(managed_object._ref) | |||
end | |||
|
|||
def rbvmomi_to_basic_types(obj) |
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.
Ideally we could just do obj.to_h
and the RbVmomi classes would support this, going to work on an rbvmomi PR to add this
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.
My change for this actually got merged but hasn't been released yet, I'll update this when a release is cut
ffacb3e
to
1ecbe28
Compare
return cs | ||
|
||
source.with_provider_connection do |vim| | ||
vim.getVimCustomizationSpecManager.getCustomizationSpec(cs.name)&.spec |
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.
The CustomizationSpec has a number of properties where the VIM class matters (e.g.: CustomizationLinuxOptions
vs CustomizationWinOptions
) so we can't just use the standard hash stored in the DB
Previously this was a serialized VimHash which included the class names (we'll need a migration to clean these up, didn't realize that CustomizationSpec#spec
was the full vim object)
Fetching the spec from the vcenter seemed to be the best option, other option is to add the VIM class name as a hash key when we convert from the native object to a hash in the parser as something like a :_xsiType
key but the user would be able to modify those in the provision dialog unless we strip them out.
I'm open to other ideas though
@agrare Do you think we can get this in in time for jansa-1 release? I'd rather not have this regression in the release if we can avoid it. |
def retrieve_customization_spec(spec_manager, cached_props) | ||
cached_props[:info].to_a.each do |spec_info| | ||
spec_info.props[:spec] = spec_manager.GetCustomizationSpec(:name => spec_info.name)&.spec | ||
rescue RbVmomi::Fault => err |
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.
If the failure occur in the middle of the loop, does this move on or end the loop?
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.
Also ewww N+1...There's no way to bulk ask this?
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.
It would move on to the next one not skip, and no unfortunately not you can't get multiple customization scripts at once.
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.
This was done here previously, the other option is to get the full spec at provision time which is closer to what the vsphere client does
app/models/manageiq/providers/vmware/infra_manager/inventory/parser.rb
Outdated
Show resolved
Hide resolved
94f71d8
to
8f061a8
Compare
The collection of customization_spces with streaming refresh was missed when moving from legacy refresh
59f660c
to
2487628
Compare
2487628
to
f6ecfb0
Compare
Checked commits agrare/manageiq-providers-vmware@16d3f94~...f6ecfb0 with ruby 2.6.3, rubocop 0.69.0, haml-lint 0.28.0, and yamllint |
If possible I'd like to keep the VCRs the same otherwise every PR we backport will conflict (aka OpenStack provider). I'll mark #591 as |
Collect customization_specs (cherry picked from commit 333b9d0)
Jansa backport details:
|
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.
It seems to me that there is a typo. Please check.
props[:info].to_a.each do |spec_info| | ||
persister.customization_specs.build( | ||
:name => spec_info[:name], | ||
:typ => spec_info[:type], |
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 think it should be :type
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.
:type
is a reserved column name used by STI, :typ
is correct here used to not conflict with STI.
Here is the database table definition: https://github.com/ManageIQ/manageiq-schema/blob/master/db/migrate/20130923182042_collapsed_initial_migration.rb#L303
The collection of customization_specs with streaming refresh was missed when moving from legacy refresh because there weren't any in the VCRs for the spec tests
TODO:
Follow-up:
CustomizationSpec#spec
Replace Vim* types in CustomizationSpec#spec manageiq-schema#508Fixes #611